[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Re[2]: Bookworm Adventures Postmortem
- From: Mike Pall <mikelu-0703@...>
- Date: Sun, 18 Mar 2007 16:14:35 +0100
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