3 ms·

Looking at the LuaJIT changelog [1], it's interesting how many bugs need fixing in each version: 20 in 2.0.5 and 32 in 2.0.4. Compare this with PUC Lua [2], wh

Looking at the LuaJIT changelog [1], it's interesting how many bugs need fixing in each version: 20 in 2.0.5 and 32 in 2.0.4. Compare this with PUC Lua [2], which seems to have very few bugs: only 4 in 5.3.3 and 3 in 5.3.2. LuaJIT and PUC Lua appear to be very similar superficially ("LuaJIT is Lua, but fast"). The relative bug counts reinforce the fact that in the details, the two implementations are very different - for example, LuaJIT uses a lot of assembly language while PUC Lua is pure C89. The advantages of LuaJIT over PUC Lua seem to be performance and its FFI. I thought PUC Lua's only advantage was portability, but perhaps PUC Lua is also a generally more "correct" implementation? [1] http://luajit.org/changes.html http://luajit.org/changes.html [2] https://www.lua.org/bugs.html https://www.lua.org/bugs.html

jshmrsn 9y ago
Not only does LuaJIT have platform-specific assembly in its source, but a big part of its advantage over PUC Lua is of course that it's compiling down to machine language on the fly. And that process is also platform specific. I have definitely seen bug fixes along the lines of "fix X for Y platform's JIT output." I have also seen non-jit-related bugs impact us in production. BUT, LuaJIT really is FASTER. Even when JIT cannot be used (e.g. on iOS), it can still be several times faster than PUC Lua. And that speed is a real killer feature for us. Otherwise, we'd just use JavaScript.
- rlp 9y ago
  Do you find LuaJIT much faster than a JavaScript engine like V8? That used to be true, but I was under the impression that V8 had basically caught up (unless you need to make a lot of FFI calls, since LuaJIT is heavily optimized for that).
  - jshmrsn 9y ago
    I may be behind the times, but last I checked there was no way to use JITed JavaScript in iOS apps. Or maybe you could put JS in a hidden webview, but bridging to native was extra slow with this approach? While LuaJIT can't be JITed either on iOS, I think the general consensus is that non-jit Lua is faster than non-jit JS. I do a lot of bridging Lua to native, and that's another area where Lua is often considered more efficient. Again, these thoughts may be out of date.
versteegen 9y ago
Aside from being incredibly low on bugs (often, there are no known bugs at all, although complaints are likely to be treated as feature requests rather than bugs), PUC Lua is also far smaller, and vastly easy to hack on. There are various patches available for it. On the other hand, the guts of LuaJIT are difficult to say the least. Most opportunity to eek out a little more speed by making the code twice has dense has been taken. However I found that adding custom library routines to LuaJIT (for operations like concatenating tables) was actually pretty easy as long as you don't want to be able to JIT them (since library routines call into an internal API which is well shielded, and there's still a lot of PUC Lua code in LuaJIT). Also, LuaJIT has other extensions aside from FFI; see the website.

jshmrsn 9y ago

Not only does LuaJIT have platform-specific assembly in its source, but a big part of its advantage over PUC Lua is of course that it's compiling down to machine language on the fly. And that process is also platform specific. I have definitely seen bug fixes along the lines of "fix X for Y platform's JIT output." I have also seen non-jit-related bugs impact us in production. BUT, LuaJIT really is FASTER. Even when JIT cannot be used (e.g. on iOS), it can still be several times faster than PUC Lua. And that speed is a real killer feature for us. Otherwise, we'd just use JavaScript.

rlp 9y ago
Do you find LuaJIT much faster than a JavaScript engine like V8? That used to be true, but I was under the impression that V8 had basically caught up (unless you need to make a lot of FFI calls, since LuaJIT is heavily optimized for that).
- jshmrsn 9y ago
  I may be behind the times, but last I checked there was no way to use JITed JavaScript in iOS apps. Or maybe you could put JS in a hidden webview, but bridging to native was extra slow with this approach? While LuaJIT can't be JITed either on iOS, I think the general consensus is that non-jit Lua is faster than non-jit JS. I do a lot of bridging Lua to native, and that's another area where Lua is often considered more efficient. Again, these thoughts may be out of date.

versteegen 9y ago

Aside from being incredibly low on bugs (often, there are no known bugs at all, although complaints are likely to be treated as feature requests rather than bugs), PUC Lua is also far smaller, and vastly easy to hack on. There are various patches available for it. On the other hand, the guts of LuaJIT are difficult to say the least. Most opportunity to eek out a little more speed by making the code twice has dense has been taken. However I found that adding custom library routines to LuaJIT (for operations like concatenating tables) was actually pretty easy as long as you don't want to be able to JIT them (since library routines call into an internal API which is well shielded, and there's still a lot of PUC Lua code in LuaJIT). Also, LuaJIT has other extensions aside from FFI; see the website.