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