Re: [ANN] LuaJIT Roadmap 2011

[David Manura <dm.lua@...>]

On Wed, Jan 26, 2011 at 9:02 PM, Miles Bader <miles@gnu.org> wrote:
> FFI seems very cool but the reliance on LuaJIT is an issue.  For normal
> Lua programs, the fact that one can fall back to the portable Lua
> implementation is a very nice property.
>
> So I'm wondering:  if your C parser is (theoretically) usable outside of
> LuaJIT, maybe it could be used as part of a tool that automatically
> generates traditional Lua-C interface functions, which could then be
> used when LuaJIT isn't available -- on systems where LuaJIT _was_
> available, of course, one would use fast FFI (choosing between the two
> alternatives at package build time).

That's a desirable property.  Your goal doesn't even require using the
nice C parser [1]; Alien omits it [2].  However, one concern is that
if the LuaJIT FFI stuff isn't traced (as it won't be under standard
Lua), a non-inherent artifact of the chosen API is that there can be
lots of temporary allocations and the like, causing performance to
degrade [3] by more than an order-of-magnitude, sometimes below
possible solutions in standard Lua.  Failure to trace can even happen
in certain cases with the LuaJIT VM (NYI stuff and certain
probabilistic algorithms).  There are optimization strategies in
standard Lua to address temporary allocations, but these are
counterproductive in LuaJIT [4].  So, whether we can write FFI code
once to perform optimally under multiple VM's is something to be seen.
 IMO, it's not hopeless, but some adaptations may be required.  Hard
numbers welcome ;)

[1] http://lua-users.org/lists/lua-l/2011-01/msg01340.html
[2] http://alien.luaforge.net/
[3] http://lua-users.org/lists/lua-l/2011-01/msg01466.html
[4] http://lua-users.org/lists/lua-l/2011-01/msg00984.html