Why LuaJIT's interpreter is written in assembly
lua-users.org
lua-users.org
I love Lua and code in it almost every day for fun, but yeah I'm pretty sure LuaJIT is just "done" now?
The newer versions of Lua basically implemented features that LuaJit already had or that would mean a performance trade off. I am still using Lua 5.1 (which is from 2012) because there is no reason to upgrade.
If you design something well, you don't need to push new features every year. Stability is underrated.
I'm not sure that's true. Maybe LuaJIT was never going to add the features it's missing from Lua 5.2, 5.3 and 5.4. However, when Mike Pall stepped back in 2015 [0], he had still been planning to further improve the implementation - for example with a new garbage collector [1] and "hyperblock scheduling" [2] (which remain unimplemented), plus 64-bit pointer support (which was eventually completed by other people).
[0] https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT...
I am wondering what is Mike Pall working on now.
They also believe all software, no matter how relatively small or simple, has bugs.
It is absolutely baffling. Job security fears I guess. There are so many incompetent software developers. These beliefs protect them from having to face their incomeptence.
That, and most package repository browsers have statistics and people are racing. How many times has it been downloaded? How many projects use it? How many stars did it get?
The more one liners you submit as a package, the better, it seems, as well.
E.g. closures are not yet supported by the JIT; notwithstanding this, it is a great and still very useful technology.
It has a few extras but they agree with the original luajit authors opinion that not every 5.2 feature can be made in jit.
I had high hopes for moonjit, but development on it has ceased. There are other forks—openresty and raptorjit come to mind—but they don't have feature parity.
> > Threaded code should have better branch prediction behavior than a jump table with a single dispatch point
> This is not the case anymore, at least for modern Intel processors. Starting with the Haswell micro-architecture, the indirect branch predictor got much better and a plain switch statement is just as fast as the "computed goto" equivalent. Be wary of any references about this that are from before 2013.
And now that it is 2021, ignore the pre-2018 numbers.
Somewhere in that old thread, I referenced the indirect jump performance hit from the whole Spectre/Meltdown mitigations for any Xeons you might have bought before mid-2020.
There's a nice paper from VMWare on "JumpSwitches" from USENIX '19 that is worth reading in this context.
That suggests that of the five different types of indirect jumps, some are back to being fast again - the one we are dealing with is the search jumpswitch.
I would say direct threaded execution (computed goto) is still worth it over the single dispatch jumps, particularly if you can JIT basic blocks & replace something an "add, mul, add, store" into a single basic block without unloading from registers for the whole operation, jump into that directly with CGOTO like you would do with a compiled chunk of code & build your micro-JIT one opcode at a time.