4 ms·

What's the deal with LuaJit? Why is it celebrated so much? I searched around a bit and they all talked about it being very fast, is that it? Performance? Also,

What's the deal with LuaJit? Why is it celebrated so much? I searched around a bit and they all talked about it being very fast, is that it? Performance? Also, adding support for risc-v is good news, well done!

deleted 2y ago
[deleted]
wsc981 2y ago
It's used in LÖVE [0] (and LÖVR [1] as well, I think) for this very reason. The Lua code for a game will be quite performant. --- [0]: https://love2d.org https://love2d.org [1]: https://lovr.org https://lovr.org
- 3eb7988a1663 2y ago
  Also NeoVIM
pansa2 2y ago
> is that it? Performance? Performance, size and compatibility. It's essentially a drop-in replacement for the stock Lua 5.1 implementation, with the same small size but with much higher performance. About the only downside compared to stock Lua 5.1 is that it's less portable. However, development of LuaJIT almost stopped ~10 years ago, and only seems to be picking up again recently. In terms of the language it hasn't kept up with all the changes in Lua 5.2, let alone 5.3 or 5.4. And in terms of implementation, its performance is still impressive but no longer best-in-class compared to other dynamic-language JITs (e.g. for JavaScript).
- CyberDildonics 2y ago
  Where are you seeing benchmarks that javascript can beat luajit?
  - pansa2 2y ago
    Here, for example: https://www.quora.com/Is-LuaJIT-still-faster-than-JavaScript-V8/answer/Rochus-Keller?a https://www.quora.com/Is-LuaJIT-still-faster-than-JavaScript... LuaJIT's speed is very impressive, but the optimizations it can use are limited by its desire to remain lightweight. It's understandable that JavaScript implementations, which don't have that restriction, can use different techniques and work out faster overall.
    - imtringued 2y ago
      I would like to say that something that doesn't get used, doesn't work out faster overall.
      - pansa2 2y ago
        > something that doesn't get used Sorry, you've lost me. What doesn't get used?
wavemode 2y ago
It's widely regarded as a highly performant and very well-engineered runtime for a popular language. For a long time it was the go-to implementation you would reach for if you a) wanted lua scripting (common in game development) and b) wanted high performance. I think nowadays though, the landscape has changed quite a bit since when luajit was at its peak of popularity. a) Lua is not necessarily the language one would always choose for scripting, in the first place. There's lots and lots of scripting languages to choose from these days. (It's also increasingly common nowadays for indie gamedev to happen entirely within a game editor, like Unity or Unreal, which provide their own scripting systems. That fact alone has killed a lot of interest in lua.) b) If you do want to use lua, the features of the official implementation have progressed a lot since v5.1 (which luajit is pinned to), and its performance has improved over the years. c) There are other competing lua and lua-adjacent implementations to consider as well, like OpenResty's luajit2 or Roblox's Luau.
- wruza 2y ago
  b) You don’t really need these features cause Luas 5.x are mostly rehashes of the ideas rather than successive versions. The team should have frozen it at 5.1, backport everything useful (yield across * basically) from 5.2 and call it done, only fixing bugs and tuning performance. That’s essentially what LuaJIT did/does. Instead the “upstream” has 4 versions of the same thing with ecosystem and codebases fragmented as a UK flag, for no good reason. LuaJIT fixes that by being awesome, but lives under the shadow of n+1 stereotype, despite being a true engineering project rather than a chain of experiments. Tbh I’m glad I left Lua world many years ago.
  - mardifoufs 2y ago
    I'm more familiar with luajit than Lua itself (as a project I mean). I'd be curious to know more about the fragmentation that vanilla Lua has. I know the issues that the luajit devs have with the features themselves but I wonder how and why those are decided and implemented. Is there an article or blog that goes into more details? Google isn't helping me here haha.
    - 2y ago
ireanst33 2y ago
[dead]
edflsafoiewq 2y ago
It's also tiny (like half a meg compiled) and has some nice extensions, like one of the best FFIs in any language.
haberman 2y ago
LuaJIT completely upended my view of what a JIT compiler could be. I always thought that JVM-like overheads were inevitable for high-performing JIT compilers. When I saw how small and low-overhead LuaJIT is, I was blown away. Here are some numbers: Lines of code: OpenJDK HotSpot (1.4M), LuaJIT: (92k) Binary size: OpenJDK HotSpot server/libjvm.so (24MB), LuaJIT: (576KB) Time to run "Hello, World": OpenJDK HotSpot (64ms), LuaJIT (3ms) (the JVM has improved here, it used to take hundreds of milliseconds) For me personally, LuaJIT's small size and low overheads set a new standard for what I expect from JIT compiled runtimes. I also find its small code base makes it approachable to learn from. I won't say that reading the code is easy, but I at least have confidence that whenever I have a question about fast interpreters or JIT compiling techniques, I can find the relevant part of the LuaJIT code and study it. Larger code bases can feel so sprawling that it's hard to ever find the snippet of code that will answer a question.
- pjmlp 2y ago
  Comparing apples to oranges, given what Lua and Java offer in features.
  - canadianfella 2y ago
    [dead]
sroussey 2y ago
It’s small size and fast performance means it can be implemented in a webserver (OpenResty’s luajit2.1) where you can write code that would tap into the TLS handshake and write a custom implementation (like connecting to a database of certificates because you serve 10s of millions of domains).
matheusmoreira 2y ago
Yes, performance. It got to the point that there are languages out there that compile to Lua or LuaJIT VM bytecode directly just to take advantage of the LuaJIT implementation. Apparently it's so good it spawned a separate language when the people at PUC-Rio started taking Lua in a direction that LuaJIT didn't want to follow.
deleted 2y ago
[deleted]

deleted 2y ago

[deleted]

wsc981 2y ago

It's used in LÖVE [0] (and LÖVR [1] as well, I think) for this very reason. The Lua code for a game will be quite performant. --- [0]: https://love2d.org https://love2d.org [1]: https://lovr.org https://lovr.org

3eb7988a1663 2y ago
Also NeoVIM

pansa2 2y ago

> is that it? Performance? Performance, size and compatibility. It's essentially a drop-in replacement for the stock Lua 5.1 implementation, with the same small size but with much higher performance. About the only downside compared to stock Lua 5.1 is that it's less portable. However, development of LuaJIT almost stopped ~10 years ago, and only seems to be picking up again recently. In terms of the language it hasn't kept up with all the changes in Lua 5.2, let alone 5.3 or 5.4. And in terms of implementation, its performance is still impressive but no longer best-in-class compared to other dynamic-language JITs (e.g. for JavaScript).

CyberDildonics 2y ago
Where are you seeing benchmarks that javascript can beat luajit?
- pansa2 2y ago
  Here, for example: https://www.quora.com/Is-LuaJIT-still-faster-than-JavaScript-V8/answer/Rochus-Keller?a https://www.quora.com/Is-LuaJIT-still-faster-than-JavaScript... LuaJIT's speed is very impressive, but the optimizations it can use are limited by its desire to remain lightweight. It's understandable that JavaScript implementations, which don't have that restriction, can use different techniques and work out faster overall.
  - imtringued 2y ago
    I would like to say that something that doesn't get used, doesn't work out faster overall.
    - pansa2 2y ago
      > something that doesn't get used Sorry, you've lost me. What doesn't get used?

wavemode 2y ago

It's widely regarded as a highly performant and very well-engineered runtime for a popular language. For a long time it was the go-to implementation you would reach for if you a) wanted lua scripting (common in game development) and b) wanted high performance. I think nowadays though, the landscape has changed quite a bit since when luajit was at its peak of popularity. a) Lua is not necessarily the language one would always choose for scripting, in the first place. There's lots and lots of scripting languages to choose from these days. (It's also increasingly common nowadays for indie gamedev to happen entirely within a game editor, like Unity or Unreal, which provide their own scripting systems. That fact alone has killed a lot of interest in lua.) b) If you do want to use lua, the features of the official implementation have progressed a lot since v5.1 (which luajit is pinned to), and its performance has improved over the years. c) There are other competing lua and lua-adjacent implementations to consider as well, like OpenResty's luajit2 or Roblox's Luau.

wruza 2y ago
b) You don’t really need these features cause Luas 5.x are mostly rehashes of the ideas rather than successive versions. The team should have frozen it at 5.1, backport everything useful (yield across * basically) from 5.2 and call it done, only fixing bugs and tuning performance. That’s essentially what LuaJIT did/does. Instead the “upstream” has 4 versions of the same thing with ecosystem and codebases fragmented as a UK flag, for no good reason. LuaJIT fixes that by being awesome, but lives under the shadow of n+1 stereotype, despite being a true engineering project rather than a chain of experiments. Tbh I’m glad I left Lua world many years ago.
- mardifoufs 2y ago
  I'm more familiar with luajit than Lua itself (as a project I mean). I'd be curious to know more about the fragmentation that vanilla Lua has. I know the issues that the luajit devs have with the features themselves but I wonder how and why those are decided and implemented. Is there an article or blog that goes into more details? Google isn't helping me here haha.
  - 2y ago

ireanst33 2y ago

[dead]

edflsafoiewq 2y ago

It's also tiny (like half a meg compiled) and has some nice extensions, like one of the best FFIs in any language.

haberman 2y ago

LuaJIT completely upended my view of what a JIT compiler could be. I always thought that JVM-like overheads were inevitable for high-performing JIT compilers. When I saw how small and low-overhead LuaJIT is, I was blown away. Here are some numbers: Lines of code: OpenJDK HotSpot (1.4M), LuaJIT: (92k) Binary size: OpenJDK HotSpot server/libjvm.so (24MB), LuaJIT: (576KB) Time to run "Hello, World": OpenJDK HotSpot (64ms), LuaJIT (3ms) (the JVM has improved here, it used to take hundreds of milliseconds) For me personally, LuaJIT's small size and low overheads set a new standard for what I expect from JIT compiled runtimes. I also find its small code base makes it approachable to learn from. I won't say that reading the code is easy, but I at least have confidence that whenever I have a question about fast interpreters or JIT compiling techniques, I can find the relevant part of the LuaJIT code and study it. Larger code bases can feel so sprawling that it's hard to ever find the snippet of code that will answer a question.

pjmlp 2y ago
Comparing apples to oranges, given what Lua and Java offer in features.
- canadianfella 2y ago
  [dead]

sroussey 2y ago

It’s small size and fast performance means it can be implemented in a webserver (OpenResty’s luajit2.1) where you can write code that would tap into the TLS handshake and write a custom implementation (like connecting to a database of certificates because you serve 10s of millions of domains).

matheusmoreira 2y ago

Yes, performance. It got to the point that there are languages out there that compile to Lua or LuaJIT VM bytecode directly just to take advantage of the LuaJIT implementation. Apparently it's so good it spawned a separate language when the people at PUC-Rio started taking Lua in a direction that LuaJIT didn't want to follow.

deleted 2y ago

[deleted]