Comment by epcoa

Vanilla Lua traditionally doesn’t show any substantial difference to python or ruby. You’re probably talking about LuaJIT in interpreter mode (jit off).

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> consistently 5-10x faster than similar languages like Python or Ruby

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Python and Ruby have had steady increments of improvement over the last decade.

> Lua without JIT is one of the fastest interpreted languages.

Maybe I should say it is "still slow". Of course you can find examples of 5-10x over python performance (not that this is saying much), this is not the norm. There's just no way, PUC-Lua is still fundamentally dynamic hash tables for lookup with a big switch statement, there's a certain limit to how fast this can go. Let's just say there are plenty of game devs that have found that Lua quickly becomes too slow for the task it has been pressed into which then becomes an exercise of exporting more and more stuff to C++ or whatever. There is Luau of course, which sort of proves this point.

These interlanguage comparisons are mostly meaningless anyway. Python may be slow, but you do the heavy lifting in other ways and that ecosystem is huge. Since the Lua ecosystem is small though you are usually on your own. LuaJIT FFI is sorta cool, but wrapping can still be a PITA.

> Maybe you’re comparing it to AOT systems languages like C and C++? That’s obviously not fair.

Or C#/.NET/Java/Kotlin/JVM. Which you can often use as part of a plugin system.

> this is the first time I’ve heard someone claim it’s slow.

Quite ironic to say this, because I'm pretty sure this is why Mike Pall created LuaJIT in the first place. For example http://lua-users.org/lists/lua-l/2011-02/msg00742.html (but there are many other great in depth essays in the archive)

> LuaJIT is also one of the most advanced JIT compilers out there, frequently beating V8 and others.

No it's not these days. LuaJIT is awesome and may have been alien technology in 2005 but has a lot of missing functionality compared to the most advanced JIT implementations.

There were of course many examples of LuaJIT beating V8 on particular microbenchmarks through the years, and many of these are rehashed from over a decade ago and are outdated. I wouldn't say this means it "frequently" beats V8, especially in a practical sense.

Anyone that has much experience with LuaJIT and has stared at a few traces is aware of "NYI" - there is a ton of stuff that is not implemented in the JIT and means fallback to the interpreter, including even pedestrian uses of closures: https://github.com/tarantool/tarantool/wiki/LuaJIT-Not-Yet-I.... There is a ton of stuff that current V8 does to optimize real world larger applications that LuaJIT JIT will bail on.

LuaJIT does well when you write code in a particular style that exploits its strengths. It's not quite as amazing for general purpose use.

Elsewhere you suggest that a GC rewrite is actively being developed, but LuaJIT development has slowed tremendously, the mailing list is not very active and I wouldn't be holding my breath for anything major (this new GC has been talked about for well over a decade).

This is strictly about how much memory LuaJIT can address on that platform. There’s no “significant performance issues”. If your workload fits inside 2 GiB (IIRC) it will be fast. LuaJIT is a world class JIT.

For a long time a new garbage collector has been an open issue for LuaJIT, which would fix this particular issue, and make the language even faster. Last I checked this was actively being worked on.