Re: LuaJIT roadmap 2008

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

Jean-Claude Wippler wrote:
> There are many cases where I need to call a Lua function from C in a very 
> tight loop.  The function is often simple, i.e. "function (r) return r.a > 
> 12 end".  Do you expect LuaJIT to be able to optimize this well when called 
> a large number of times in succession?  It would be grand if this ends up 
> becoming an int comparison (guarded by a check, of course).  Let me add 
> that "r" is a userdata object, not a table.

Well, that's only 3 bytecode instructions you're feeding to the
compiler here. And that userdata lookup looks like you're calling
a getter method in C. The trace compiler cannot trace into C
functions nor can it trace downwards to a calling C function.

This means none of the type checks or metatable lookups can be
optimized away. Calling a "black-box" C function (the getter
method) is like calling a volatile function in C. The compiler
cannot assume anything about its effects and has to disable all
optimizations.

[I may later add an option to give hints to the compiler that
certain C functions are pure, or read-only or at least have only
certain side-effects. But this won't help much here either.]

Ok, so the faster interpreter and the faster calling conventions
will make this go faster than in plain Lua. But compiling it
would not improve this code snippet much.

If, on the other hand:

a) the loop you mention is re-written in Lua,
b) the variable r is a table, and
c) r.a is a plain table field lookup.

... then the compiler could probably optimize most of the
overhead away. I'm pretty sure it would run faster altogether
than the mixed C/Lua/C solution you have now. And after inlining
and specialization of the callbacks (adapting to runtime
behaviour) it might even run faster than a pure C solution.

Rules of thumb: write all of it in Lua, use Lua tables
exclusively for data structures, avoid frequent upcalls from C to
Lua, avoid calling "black-box" C functions in tight loops.

I realize this is not so easy when retrofitting an existing
design. But it's something to keep in mind when planning a new
application.

--Mike