Re: [ANN] LuaJIT-2.0.0-beta1

[Geoff Leyland <geoff_leyland@...>]

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.

Cheers,
Geoff