Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

The Great Computer Language Shootout

 [1/7] from: petr::krenzelok::trz::cz at: 3-Jan-2002 22:06


For those interested in language comparisons, look at following site: http://www.bagley.org/~doug/shootout/ If someone finds enough free time, ti would be interesting to see, how rebol scores :-) -pekr-

 [2/7] from: pwoodward:cncdsl at: 3-Jan-2002 16:42


Petr - on a quick run-thru of the Ackermann function - w/o optimization: ackermann: function [x y] [] [ if x = 0 [ return y + 1 ] if y = 0 [ return ackermann x - 1 1 ] return ackermann x - 1 ackermann x y - 1 ] started: now/time for i 1 8 1 [ print ackermann 3 i ] print ["elapsed time" now/time - started] I get a stack overflow if I allow y to grow to 8, but it takes 11 seconds to get to 7.... - Porter

 [3/7] from: pwoodward:cncdsl at: 3-Jan-2002 16:52


Also - I added something to slow the function calls down a bit - just to see how many times it recurses with y growing to 7... 13 29 61 125 253 509 1021 elapsed time 0:00:12 function calls: 922021 - Just under 1 million recursions - I guess I see why REBOL ran out of stack space! On a related note - I know we can find out how much memory REBOL is using, but how can I find out how much CPU time? My usage of now/time is a very unaccurate measure of how much computational power was expended - what with IE, OE, Tomcat and other apps running simultaneously. - Porter

 [4/7] from: joel:neely:fedex at: 3-Jan-2002 16:57


Hi, Petr, Petr Krenzelok wrote:
> For those interested in language comparisons, look at following > site: http://www.bagley.org/~doug/shootout/ > > If someone finds enough free time, ti would be interesting to see, > how rebol scores :-) >
I looked at this site a while back, but abandoned the effort of running the tests in REBOL after the very first one failed to complete... The first test is the Ackermann function, computed for a (3, 4) through a (3, 8). I coded the function in REBOL, and got the following results: a: func [x [integer!] y [integer!]] [ either x = 0 [ y + 1 ][ either y = 0 [ a x - 1 1 ][ a x - 1 a x y - 1 ] ] ]
>> a 3 4
== 125
>> a 3 5
== 253
>> a 3 6
== 509
>> a 3 7
** Internal Error: Stack overflow ** Near: a x - 1 1
>>
I should include the remarks from the site itself that explain the role of the Ackermann benchmark: For this test, each program should be implemented in the same way. Each program should implement the recursive version of Ackermann's function illustrated below. Ackermann's function is heavily recursive, and will really stress a language's ability to do deep recursion. This test computes the value of Ack(3, N), where N ranges up to 8. Visit the detail page to see results for different values of N. Those languages that do not implement tail recursion elimination (tail-call elimination) will not peform as well as those that do. This test also appears in the Kernighan and Wyk study Timing Trials, or, the Trials of Timing: Experiments with Scripting and User-Interface Languages, where they say it will give a language's function call mechanism a workout. However, this probably isn't so accurate for languages that do tail-call elimination, since they essentially turn recursive tail-calls into iterative loops. The correct output (for N = 4) looks like this: Ack(3,4): 125 -jn-

 [5/7] from: lmecir:mbox:vol:cz at: 5-Jan-2002 13:05


Hi all, it looks like the Rebol stack depth is too low to compute ACK 3 8. That is why I wrote my version that uses a block to store intermediate results. This version is slower than a recursive version and there's no doubt that it can be optimised. ack2: function [m n] [b] [ b: make block! 0 until [ either zero? :m [ n: :n + 1 either empty? :b [ :true ] [ m: last :b remove back tail :b :false ] ] [ either zero? :n [ m: :m - 1 n: 1 ] [ n: :n - 1 insert tail :b :m - 1 ] :false ] ] :n ] Prosperous year 2002 to all Ladislav

 [6/7] from: sunandadh:aol at: 5-Jan-2002 15:02


Hi Ladislav,
> it looks like the Rebol stack depth is too low to compute ACK 3 8. That > is why I wrote my version that uses a block to store intermediate results. > This version is slower than a recursive version and there's no doubt that
it
> can be optimised. <snip>
Can I combine this thread with "Source code layout question" and ask "why the prefixed colons?" n: :n + 1 Unless I'm missing a subtle syntax issue or speed optimization, that's the same as n: n + 1 although I can see that it does lead to a slight bit of additional orthogonality in something like: mySeries: [1 2 3 4 5 5 6] n: :n + 1 print :myseries/:n where the 2nd colon is needed in the print statement. Pity we can't write: mySeries: :[1 2 3 4 5 5 6] for complete consistency <g> Sunanda.

 [7/7] from: lmecir:mbox:vol:cz at: 6-Jan-2002 9:20


Hi Sunanda, <<Sunanda>> (...) Can I combine this thread with "Source code layout question" and ask "why the prefixed colons?" n: :n + 1 Unless I'm missing a subtle syntax issue or speed optimization, that's the same as n: n + 1 (...) <</Sunanda>> It is an old code and some time ago :N was faster than N. Cheers Ladislav