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)
This certainly does help but if you're making API calls in a hot loop the marshalling and unmarshalling can still be pretty bad. ("It hurts when I do this!" "So don't do that.") At one point it was actually faster to stay in the interpreter for that, though I couldn't say if that's still true or not.
/s/ Adam
