[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaJIT-2.0.0-beta1
- From: Geoff Leyland <geoff_leyland@...>
- Date: Sun, 1 Nov 2009 21:31:56 +1300
On 1/11/2009, at 2:52 PM, Mike Pall wrote:
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).
Sorry Mike, I owe you an apology - it was clear that LJ2 was faster on
the bit that mattered (the speed test) and I didn't think clearly
about the not-for-speed integrity check - I had it in my head that it
was the integrity check itself that was slow, even though I should
have known the problem was io.
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.
Unless it's interesting to you, the test_sort_queue_speed really isn't
relevant. I think it came about because someone on the list asked how
bad it was to keep a table sorted rather than use a heap, so I checked
(if anyone's is wondering, use a heap!)
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! :-)
I'm glad it was useful nonetheless! I'll run some kdtree stuff soon,
and I'll be more careful about isolating relevant results.