>However, I stuck to the public Lua C APIs, so the resulting code ended
>up
>slower than the stock interpreter.
Lua-AOT uses the internal Lua APIs, and therefore only works with a modified version of Lua VM that exposes these APIs. It implements each VM instruction using code that is essentially copy pasted from lvm.c.
One consequence of this is that at runtime the compiled functions in Lua-AOT are also represented as "Lua closures" instead of "C closures", as would be done in something that uses the regular C API.
One related work that I can think of right now would be Gabriel Ligneuls bytecode to LLVM compiler
https://github.com/gligneul/FastLua
Another would be the Lua Vermelha JIT https://github.com/Leonardo2718/lua-vermelha
The main difference in Lua-AOT's case is that it is very simple, since it is basically just copy pasting the regular interpreter code. This makes it less suitable as a production tool, but also means it's easy to experiment with the implementation
Ravi's JIT backend is essentially the same except there are additional byte codes that are type specialised. However in 5.3 there were issues caused by differences in how functions are called in different circumstances. Maybe 5.4 is more uniform. Also coroutines are never JITed. In Ravi when JITed tail calls become regular calls.
JITing regular Lua code gives very little benefit in Ravi ... But maybe 5.4 byte codes are more specialised in some cases so you are seeing better performance than I have observed.
