Re: [ANN] LuaJIT-2.0.0-beta1

[Mike Pall <mikelu-0911@...>]

David Given wrote:
> I don't think I'm doing anything particularly stupid --- the docs say I
> don't need to do anything particular to turn the JIT on, right? I can
> just run a problem with luajit instead of lua and it'll work?

Yes, definitely.

> So assuming that I am working LuaJIT correctly there's something about
> Clue's output that it's not getting on with. As Clue's Lua output is
> mostly dead simple, my initial instinct is to blame the disgusting hack
> I'm having to do to emulate gotos:
> 
>   local state = 0
>   repeat
>     while true do
>       if state == 0 then <code for basic block 0> end
>       if state == 1 then <code for basic block 0> end
>       if ...etc.. end
>       if state == 99 then
>         <code for basic block 99>
>         state = 42 break end -- transfer to basic block 42
>       if ...etc... end
>     end
>   end
> 
> Could this be upsetting the JIT?

Well, yes, it's disgusting. :-) You are putting a loop around
something which should be mostly linear control flow. And all of
the branches inside are now much less predictable, too.

Congratulations, you've managed to brew up the perfect nightmare
for a trace compiler and a super-scalar CPU at the same time. ;-)

> (I have had thoughts about using tail calls to do the transfer of
> execution from one basic block to another, but I haven't come up with a
> decent way of doing it without doing memory allocations on entry to each
> function.)

Dunno about these allocations. But tail calls are very fast with
LJ2. The compiler turns them into an inlined goto, i.e. a no-op.

> Here's a complete short function so you can see what it's actually emitting:

Yikes. Can we come up with some nice isolated test case? E.g.
something that can be scaled to run for 0.5-10 seconds and only
does _one_ thing. Maybe translate one of the C shootout benchmarks?

--Mike