lua-users home
lua-l archive

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


I don't know of a good way to optimize this sort of thing automatically. The
introduction of

    local math_sqrt = math.sqrt

Moves two table lookups out of the inner-loop, but how would the runtime
system know that every time it looks up "math" in the globals it will get
the same table and every time it looks up "sqrt" in that table it will get
the same function?

But inability to optimize it automatically doesn't mean that there isn't an
interesting opportunity for a source code analyzer that could observe
repeated global lookups and repeated lookups into values that aren't
changing and suggest that they might be candidates for caching.

Mark

on 7/25/05 1:29 PM, Tim Gogolin at tgogolin@adobe.com wrote:

> Yes, I realize that making performance claims without mentioning
> system details is not particularly useful. For the record, that 5%
> improvement came on a Dual 2Ghz G5, running an optimized (gcc 4)
> build of the lua engine.  But regardless of platform specifics, I
> wasn't expecting that much of an improvement after only 30 seconds of
> playing with the code :-)
> 
> -- Tim Gogolin
>   Adobe Systems
> 
> On Jul 25, 2005, at 3:23 PM, Tim Gogolin wrote:
> 
>> 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