lua-users home
lua-l archive

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


Hi,

Gé Weijers wrote:
> I did a quick, unscientific test and ran an 'nfib' benchmark. 'nfib'  
> is a recursive function returning the number of function calls  
> executed. It's useful for a quick assessment of function call  
> overhead.

I don't think so. The call depth is untypical, only a single
function dominates in the execution path and it's almost
completely bound by D-cache write-back throughput. Especially the
latter overhead is hidden in most realistic scenarios.

> You can trivially speed  this program up by declaring 'nfib' as
> a local function, but I  ignored that.

Using "local" in the right places is not an optional task.
Especially not if you want to do benchmark comparisons. :-)

[ Some strange Russian/Carribean company is trying to promote
their proprietary game engine by unfair benchmarking against Lua.
They wrote the worst-possible Lua code (not using any locals of
course) and then compared against their own fully optimized
language implementation. No, I'm not going to post a link. ]

>       C: 31.20   (optimized)
>       C: 10.90   (unoptimized)
>       Lua: 1.00
>       Python: 0.35
>       Perl: 0.15

With a global function LuaJIT scores 5.3. But with a local
function LuaJIT scores 7.8. Proper use of locals is crucial for
performance.

Bye,
     Mike