Revolution, Python and bytecode optimization - A teeny math benchmark
Alex Tweedly
alex at tweedly.net
Tue Dec 7 18:30:52 EST 2004
At 08:33 07/12/2004 -0800, Gordon wrote:
>Teeny math benchmark:
>10,000,000 iterations of a loop, calculating the
>square root of the loop index on each pass.
>
>Revolution 2.5
> repeat with n = 1 to niter
> put sqrt(n) into tmp
> end repeat
>
>Time = 7.133 seconds (elapsed)
>
>Python 2.3
>while n <= niter:
> s = math.sqrt(n)
> n += 1
>
>Time = 18.1 seconds (elapsed)
><big hand-waving disclaimer>
>I know I know ... the author of this little benchmark
>is fully aware that this is just one tiny aspect of
>each langauge and that it doesn't prove anything and
>you shouldn't sell the farm based upon this etc. etc.
>... He was just curious and wanted to make the point
>about bytecode optimization.
></big hand-waving disclaimer>
I'll get around to a longer reply on the underlying issues ..... but a
quick comment on your benchmark. I read your disclaimer - but even allowing
for that, I don't understand why you used such different forms of loops to
compare.
If you're doing the Python version
>while n <= niters:
> n += 1
why not do the Rev as
>repeat while n <= niters
> add 1 to n
>end repeat
(For rev, the "repeat while" version is 60% slower than "repeat for".)
Or, otoh, why not compare
>repeat for n=1 to niters
with
>for n in range(niters):
(the "for" version is about 25% faster in Python than the "while" version)
And of course, I still can't figure out why a bytecode optimizer wouldn't
achieve what a good compiler optimizer would - i.e. eliminate the entire
loop, setting the terminal values for n and tmp.
-- Alex.
More information about the use-livecode
mailing list