lua-users home
lua-l archive

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


Geoff Leyland wrote:
> It didn't like my heap code:

Well, yes and no. First, it's easier to analyze when the different
phases are separated out to individual benchmarks. The total
execution time of all of the test is not very meaningful.

The heap integrity checks spend 90% - 95% of their time writing
output. This overwhelms the check itself. And I/O functions are
not recorded (yet).

Comparing test_heap_speed is more interesting:

        binary_heap     skew_heap
------------------------------------
Lua       11.4s         10.7s
LJ1        2.9s          4.2s
LJ2        1.6s          3.0s
         /  50% JIT       25% JIT
Profile (   40% Interp    65% Interp
         \  10% GC        10% GC

So, even though LJ2 is quite a bit faster, it still spends way too
much time in the interpreter. Upon cursory examination it looks
like this is one of the NYI items:

The innermost loops seem to run only for very few iterations. And
side exits from it return back to a lower frame than the loop
itself. This case can't be recorded, yet. So it falls back to the
interpreter instead of creating a nice side trace. Fixing this
issue is actually quite high on my list. Thank you for providing a
good test case for it! :-)

But the original test run is dominated by test_sort_queue_speed
which spends a lot of time in table.sort and table.remove. Neither
of which is supported, yet. The former is really hard, but the
latter is trivial to do for the usual "pop-last-element" case.

Ok, I've just reprioritized my TODO list a bit ... ;-)

--Mike