Re: LuaJIT 2.0 and external C libraries

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

David Given wrote:
> On 22/03/10 17:08, Mike Pall wrote:
> > Easy, huh? Ok, so there's a lot more magic going on inside. E.g.
> > you may have noticed it has hoisted the lookup of bit.bxor out of
> > the loop and narrowed everything to integer arithmetic.
> 
> I was under the impression that LuaJIT did everything using double
> precision floats. Is the narrowing-to-integer stuff new?

Maybe you're confusing this with the interpreter: it only deals
with a single form of numbers on the stack, i.e. doubles.

But the LuaJIT 2.0 JIT compiler does predictive narrowing for
induction variables and demand-driven narrowing for index
expressions using a backpropagation algorithm. Bit operations may
also be narrowed with a backpropagation algorithm, since their
semantics are defined approriately.

> If so, does
> this mean that porting to devices with poor FPUs (such as ARM) would be
> more feasible, with the bulk of the calculations happening using fast
> integer operations and floats only used for the calculations that need it?

Yes and no. It still makes heavy use of FP arithmetic in all the
cases where it's beneficial or doesn't make a difference on an
x86/x64-class CPU with a fast FPU.

The narrowing is probably not aggressive enough for FP-challenged
CPUs. Finding the right balance for a particular CPU is hard and
may require major changes to the VM. The high diversity of the ARM
ecosystem doesn't exactly help, either. An integer-only port may
still be a better option for some of these devices.

--Mike