Re: LuaJIT 2.0 and external C libraries

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

Matt Campbell wrote:
> I'd like an explanation of how LuaJIT 2.0's compiler interacts with  
> external C libraries that use the standard Lua C API.  Specifically, if  
> my Lua code calls a C function (outside the standard library) in a loop,  
> are there any circumstances in which that loop can't be compiled to  
> native code?

Such a call is not compiled at all. The trace is aborted and
LuaJIT falls back to the interpreter. Unless there's a path inside
the loop that happens not to call an unknown C function, the loop
is eventually blacklisted and runs purely in the interpreter.

Rationale: the transition to C code is too costly and the compiler
wouldn't be able to optimize across such a call, anyway.

The transition to C code requires flushing all values to the Lua
stack, setup of a new Lua stack frame and other context,
performing the actual call to the C function, which in turn calls
back into the Lua/C API multiple times to fetch its arguments from
the stack frame etc.. This dominates the cost of calling short C
functions and the interpreter is not that much slower then.

The planned FFI will fix that and will allow direct inlining of
calls to C functions.

Morale: use pure Lua code for your inner loops. Trivial C helper
functions don't pay off and may turn out to be slower than
equivalent Lua code.

> My guess is that LuaJIT compiled code can't interact with  
> external C functions as efficiently as it does with standard library  
> functions that have fast paths in assembler.  But I'd like to know more  
> about how this works.

Whether a function has a fast path in the assembler or not is
orthogonal to whether the compiler is able to deal with it or not.
It's just that the internal functions that _do_ have fast paths,
are those with the biggest payoff. So they usually happen to have
an equivalent recording handler in the compiler, too.

Actually the fast paths in the interpreter are never called from
compiled code. The trace recorder recogizes a known function and
simulates the fast path by recording the appropriate IR instead.
This can be as simple as a single instruction (see below) or a
maze of conditions and transformations (e.g. string.sub).

Simple example:

  luajit -jdump -e "local x=0; for i=1,100 do x=bit.bxor(x,i) end"

The trace recorder follows the bytecode and recognizes a call to
the bit.bxor function:

0006  GGET     5   0      ; "bit"
0007  TGETS    5   5   1  ; "bxor"
0008  MOV      6   0
0009  MOV      7   4
0010  CALL     5   2   3
0000  . FUNCC               ; bit.bxor  <------
0011  MOV      0   5
0012  FORL     1 => 0006

This is turned into the equivalent IR (only the inner loop shown):

0020 ------ LOOP ------------
0021    num TONUM  0017
0022  + int BXOR   0018  0017           <------
0023  + int ADD    0018  +1  
0024 >  int LE     0023  +100
0025    int PHI    0018  0023
0026    int PHI    0017  0022

And then compiled to machine code:

->LOOP:
394cfff0  xor ebp, ebx                  <------
394cfff2  add ebx, +0x01
394cfff5  cmp ebx, +0x64
394cfff8  jle 0x394cfff0	->LOOP
394cfffa  jmp 0x394c001c	->3

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.

--Mike