lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Interesting. Out of curiosity, I went to the shootout website and picked a random benchmark (n-body), and looked for trivial optimizations that hadn't been made... 

Replacing
           x = math.sqrt( y )
with
x = math_sqrt( y ) -- make math_sqrt a local that is defined above the inner loop code
saves several thousand table lookups and chops 5% off the runtime. So apparently there really are trivial changes we could do to improve lua's performance in these benchmarks... Is this enough of a well known resource that it would be worth improving lua's performance for? (Apologies if that is a silly question) 

-- Tim Gogolin
Adobe Systems



Yes, there is.

1. Some of the Lua benchmarks there are not optimized.
I've hand-optimized a few of them (with sizeable gains), but
I've not had the time to clean them up and submit them, yet.

2. They've added quite a few new benchmarks recently and not
all of them have Lua equivalents, yet. This has a very negative
impact on the ranking, too.

3. Another problem is that they are using a Lua binary that has
the Lua core compiled as a shared library. Unfortunately this
comes with a sizeable performance loss on x86 CPUs. Since the
other languages are statically compiled, the comparison is
not completely fair.

Note: Yes, all of this is our (the Lua community's) fault.
The shootout maintainers just take whatever the respective
language community gives them. IMHO we should do something
about it. It's not good for Lua PR.

Could someone else please step up and take the lead for
fixing #1 and #2? I will gladly send my optimized versions
to anyone's mailbox. I have: ackermann, count-words, random,
spellcheck, tcp-echo, threads, threads-flow, word-frequency.
[All the others I optimized have been removed from the shootout.]

We already discussed #3 in March/April with no immediate
solution.

Bye,
     Mike