← Back to context

Comment by aeadio

1 year ago

Lua without JIT is one of the fastest interpreted languages. In fact it might just be the fastest. LuaJIT is also one of the most advanced JIT compilers out there, frequently beating V8 and others.

There are very valid complaints about Lua. It lacks useful quality of life features. Some of its design decisions grate on users coming from other languages. Its standard library is barebones verging on anemic, and its ecosystem of libraries does not make up for it.

But after using Lua in many places for well over a decade, I’ve gotta say, this is the first time I’ve heard someone claim it’s slow. Even without JIT, just interpreter to interpreter, it’s consistently 5-10x faster than similar languages like Python or Ruby. Maybe you’re comparing it to AOT systems languages like C and C++? That’s obviously not fair. But if you put LuaJIT head to head with AOT systems languages you’ll find it’s within an order of magnitude, just like all the other high quality JITs.

3 comments

aeadio

Reply
epcoa  1 year ago

> 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).