3 ms·

Why LuaJIT's interpreter is written in assembly

81 points by obl 6y ago

guenthert 6y ago
That needs an 2011 tag.
remexre 6y ago
I wonder if Clang can do better these days; I noticed that it seems to merge computed gotos to normal-looking control-flow (I suppose this is necessary for alias analysis).
- nn3 6y ago
  Also modern compilers should be able to use frequency information from profile feedback to inform the register allocator. So it's unclear the static register allocation scheme is really that much better.
pansa2 6y ago
Relevant: > > 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. https://news.ycombinator.com/item?id=15396761 https://news.ycombinator.com/item?id=15396761
- gopalv 6y ago
  > 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.
  - rurban 6y ago
    The only difference of these two variants is that cgoto skips the switch range check at the beginning. Switch is largely implemented as such a jump table also. Compilers didn't get that smart yet to optimize switch tables to something better, even if it's constant. A vm or jit on the other hand could exploit bitmasks of ops or neighbor frequencies of ops better. LuaJit did that by hand.
- deleted 6y ago
  [deleted]
newobj 6y ago
Is LuaJIT still under active development? I thought the developer had walked away. With Torch also looking dead, that use case is gone, too. Roblox has their own Lua VM now. I love Lua and code in it almost every day for fun, but yeah I'm pretty sure LuaJIT is just "done" now?
- BugsJustFindMe 6y ago
  The git repo weirdly continues to get periodic updates. I think it just doesn't get features anymore?
- cardanome 6y ago
  LuaJit is simply feature complete. There are is nothing to add to it. 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.
  - pansa2 6y ago
    > There is nothing to add to it. 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-maintainers https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... [1] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector [2] https://github.com/LuaJIT/LuaJIT/issues/37 https://github.com/LuaJIT/LuaJIT/issues/37
    - ksec 6y ago
      I think he dislike the direction Lua was moving and he doesn't intend to implement any of those newer Lua features. So he stopped working on it. I am wondering what is Mike Pall working on now.

81 points by obl 6y ago

That needs an 2011 tag.

I wonder if Clang can do better these days; I noticed that it seems to merge computed gotos to normal-looking control-flow (I suppose this is necessary for alias analysis).

nn3 6y ago
Also modern compilers should be able to use frequency information from profile feedback to inform the register allocator. So it's unclear the static register allocation scheme is really that much better.

pansa2 6y ago

Relevant: > > 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. https://news.ycombinator.com/item?id=15396761 https://news.ycombinator.com/item?id=15396761

gopalv 6y ago
> 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.
- rurban 6y ago
  The only difference of these two variants is that cgoto skips the switch range check at the beginning. Switch is largely implemented as such a jump table also. Compilers didn't get that smart yet to optimize switch tables to something better, even if it's constant. A vm or jit on the other hand could exploit bitmasks of ops or neighbor frequencies of ops better. LuaJit did that by hand.
deleted 6y ago
[deleted]

newobj 6y ago

Is LuaJIT still under active development? I thought the developer had walked away. With Torch also looking dead, that use case is gone, too. Roblox has their own Lua VM now. I love Lua and code in it almost every day for fun, but yeah I'm pretty sure LuaJIT is just "done" now?

BugsJustFindMe 6y ago
The git repo weirdly continues to get periodic updates. I think it just doesn't get features anymore?
cardanome 6y ago
LuaJit is simply feature complete. There are is nothing to add to it. 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.
- pansa2 6y ago
  > There is nothing to add to it. 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-maintainers https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... [1] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector [2] https://github.com/LuaJIT/LuaJIT/issues/37 https://github.com/LuaJIT/LuaJIT/issues/37
  - ksec 6y ago
    I think he dislike the direction Lua was moving and he doesn't intend to implement any of those newer Lua features. So he stopped working on it. I am wondering what is Mike Pall working on now.