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