Re: [ANN] LuaJIT Roadmap 2011

[Miles Bader <miles@...>]

David Manura <dm.lua@math2.org> writes:
>> 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.

Sure, by trying to maintain portability this way, one probably couldn't
take full advantage of the FFI, and would need to design the interface
with the limitations of the non-tracing implementation in mind.

Still, I think there are probably many cases where such constraints
would be manageable, and justified by the advantages of portability.
The LuaJIT / FFI version would probably much faster in many cases,
simply by avoiding the overhead of the interface wrappers, but hopefully
the pure-Lua version would still be "good enough", and by sharing the
same definition, would not need special attention/maintenance.

-miles

-- 
Christian, n. One who follows the teachings of Christ so long as they are not
inconsistent with a life of sin.