On Thu, 23 Jan 2020 at 10:00, Coda Highland <chighland@gmail.com> wrote:
> I imagine the issue being alluded to is that LuaJIT has to disable compilation around functions implemented using the C API. It has to entirely throw away any assumptions it can make about the Lua state because a Lua C function can do literally anything to it and the JIT has no way to know about it. If you're using Lua C functions, you're basically getting the advantages of LuaJIT's hand-tuned-asm interpreter but losing out on most of the advantage of compilation.
... and of course, with trace stitching the overhead is much smaller
and doesn't abort tracing. you get JITted code with a short call to
the interpreter to handle the API call (and to ensure the interpreter
is in a sane state, allowing for any lua_* call)
Ah, yes, that's my understanding as well.
This is not the first time the ambiguity between LuaJIT (the tracing JIT) and LuaJIT (the complete Lua runtime) has bit me!
I would agree that, where available, the FFI is preferable to the C API.
cheers,
-Sam
