5 ms·

It would be interesting to know how many projects are using regular Lua vs LuaJIT, as the two implementations have diverged. When both were on version 5.1, the

by pansa2 6y ago

It would be interesting to know how many projects are using regular Lua vs LuaJIT, as the two implementations have diverged. When both were on version 5.1, there didn't seem to be any downsides to LuaJIT. Many Lua projects could benefit from it as long as they weren't trying to run on a platform that disallows JIT compilation (e.g. iOS or a game console). However, now that LuaJIT is 2-3 language versions out-of-date, and has different best-practices (e.g. around FFI), it's almost like the two are different languages.

kzrdude 6y ago
Every major release of Lua has always been a different language, and embedding in general encourages not upgrading. If you ship something based on Lua 5.2, how to handle all existing user scripts if you upgrade Lua?
otabdeveloper4 6y ago
> When both were on version 5.1, there didn't seem to be any downsides to LuaJIT. LuaJIT has (had?) weird memory limits due to its GC implementation. This matters if you're running scripts on a server.
upofadown 6y ago
I think we do have to call this a legitimate language fork at this point. Prosody (XMPP server) runs on 5.2 and does not require LuaJIT. The LuaJIT thing is more of a symptom than a cause.
fwsgonzo 6y ago
Performance-wise Lua is not too far behind LuaJIT that you should just "never" use Lua. I used Lua for a long time without problems, and in the cases where you need that extra performance you are just one "system call" away from native performance for that specific operation. I used to benchmark these things (for my use cases) for a long time, and Lua was always somewhere between 50-100% slower than LuaJIT, which is NOT a lot. It's a mistake to think that people implement Mandelbrot as a script callback. :) It's unfortunate that LuaJIT fell behind so much, but as far as game engines who need a scripting language goes: You are either safe with Lua, or you have other alternatives: JavaScript, WASM, dynamic libraries and so on.
- WaltPurvis 6y ago
  100% slower seems like a lot.
  - schwartzworld 6y ago
    not as much as 200% slower
- cellularmitosis 6y ago
  I recently redid the graphs of the luajit benchmark results to highlight performance across architectures: https://gist.github.com/cellularmitosis/55ff55b55008b2f1c42b4d0e46f58c76 https://gist.github.com/cellularmitosis/55ff55b55008b2f1c42b...
  - fwsgonzo 6y ago
    Nice work, man. I was doing microbenchmarks where I among other things measure the 90ns (JIT) and 120ns (Regular) function call overhead of Lua. My benchmarks was compared to my own scripting backend where the call overhead is 4ns, and it always feels a little bit like cheating when you have a gigantic headstart with each test. I'm not surprised the JIT isn't that good, but this is crazy almost! Did you compare against the latest version of Lua? https://gist.github.com/fwsGonzo/f874ba58f2bab1bf502cad47a9b2fbed https://gist.github.com/fwsGonzo/f874ba58f2bab1bf502cad47a9b... In my microbenchmarks LuaJIT was always faster than Lua, but not so much that I wouldn't stop using Lua. In my mind once you stop developing a language it stops being interesting, because you are always looking for ways to simplify and remove whole classes of bugs. EDIT: I just built lua5.4 from sources and ran my benchmarks again, and it's markedly worse than LuaJIT still, but it's better than before for sure. My conclusion is that Lua5.4 is the fastest PUC-Lua yet. https://gist.github.com/fwsGonzo/2f4518b66b147ee657d64496811f9edb https://gist.github.com/fwsGonzo/2f4518b66b147ee657d64496811...
    - anonymoushn 6y ago
      Some of these benchmarks are maybe not how one would do things if they were trying to go fast. An unfortunate idiom I wrote a thousand times at a company that uses Lua and tries to go fast is local n = 0 local t = {} -- to do an insert n = n + 1 t[n] = blorp -- to delegate some inserts to another function n = insert_some_stuff(t,n) A less messy thing you could do is local table_insert = table.insert but this is not as great, because lua will still do a binary search to find the end of the array each time you insert something.
as-j 6y ago
We chose to go with Lua on our embedded project ~2 years ago, and chose lua 5.3 with the following rational: 1. Lua embeds well on a small system and gives us a higher level language than C. lua or luajit is ok 2. Lua isn't being used for performant code. If we have performance issues use C. 3. LuaJit is looking for a maintainer and is stagnant. This isn't desirable. Not sure if this is "best practice" but it summarized how we worked through it. Lua 5.4 has some appealing benefits for us, we'll give it a few patch releases, but I look forward to moving to it. Re Performance: We're actually running from 50Hz code in Lua on an old embedded CPU. We haven't re-written that in C yet since it runs just fine. We're been constantly surprised at how well it runs and works for us.
andrewmcwatters 6y ago
If you use LuaJIT, you can generate bindings to C libraries, versus handwriting bindings for PUC Lua. The productivity difference is staggering. Additions to Lua since 5.1.5 have not helped me write more or better software, as much as I love Lua.
alexhutcheson 6y ago
LuaJIT: + Super easy FFI to C + Very fast (although profile to make sure this matters) PUC Lua: + Possible to run untrusted code (e.g. user scripts) in a sandbox + Will run on a huge variety of platforms, including many microcontrollers (only limiting factor is a C compiler and a mostly-complete libc) + Has some additional language features (although some features, including integers, are controversial) + Actively maintained, expected to receive new releases and updates
- colejohnson66 6y ago
  What does PUC mean in “PUC Lua”?
  - deleted 6y ago
    [deleted]
  - riidom 6y ago
    https://en.wikipedia.org/wiki/Pontifical_Catholic_University_of_Rio_de_Janeiro https://en.wikipedia.org/wiki/Pontifical_Catholic_University...
  - alexhutcheson 6y ago
    PUC-Rio[1] which is the university where the original authors and current maintainers work. See "Where does Lua come from?" here: https://www.lua.org/about.html https://www.lua.org/about.html [1] https://www.puc-rio.br/english/ https://www.puc-rio.br/english/

by pansa2 6y ago

kzrdude 6y ago

Every major release of Lua has always been a different language, and embedding in general encourages not upgrading. If you ship something based on Lua 5.2, how to handle all existing user scripts if you upgrade Lua?

otabdeveloper4 6y ago

> When both were on version 5.1, there didn't seem to be any downsides to LuaJIT. LuaJIT has (had?) weird memory limits due to its GC implementation. This matters if you're running scripts on a server.

upofadown 6y ago

I think we do have to call this a legitimate language fork at this point. Prosody (XMPP server) runs on 5.2 and does not require LuaJIT. The LuaJIT thing is more of a symptom than a cause.

fwsgonzo 6y ago

Performance-wise Lua is not too far behind LuaJIT that you should just "never" use Lua. I used Lua for a long time without problems, and in the cases where you need that extra performance you are just one "system call" away from native performance for that specific operation. I used to benchmark these things (for my use cases) for a long time, and Lua was always somewhere between 50-100% slower than LuaJIT, which is NOT a lot. It's a mistake to think that people implement Mandelbrot as a script callback. :) It's unfortunate that LuaJIT fell behind so much, but as far as game engines who need a scripting language goes: You are either safe with Lua, or you have other alternatives: JavaScript, WASM, dynamic libraries and so on.

WaltPurvis 6y ago
100% slower seems like a lot.
- schwartzworld 6y ago
  not as much as 200% slower
cellularmitosis 6y ago
I recently redid the graphs of the luajit benchmark results to highlight performance across architectures: https://gist.github.com/cellularmitosis/55ff55b55008b2f1c42b4d0e46f58c76 https://gist.github.com/cellularmitosis/55ff55b55008b2f1c42b...
- fwsgonzo 6y ago
  Nice work, man. I was doing microbenchmarks where I among other things measure the 90ns (JIT) and 120ns (Regular) function call overhead of Lua. My benchmarks was compared to my own scripting backend where the call overhead is 4ns, and it always feels a little bit like cheating when you have a gigantic headstart with each test. I'm not surprised the JIT isn't that good, but this is crazy almost! Did you compare against the latest version of Lua? https://gist.github.com/fwsGonzo/f874ba58f2bab1bf502cad47a9b2fbed https://gist.github.com/fwsGonzo/f874ba58f2bab1bf502cad47a9b... In my microbenchmarks LuaJIT was always faster than Lua, but not so much that I wouldn't stop using Lua. In my mind once you stop developing a language it stops being interesting, because you are always looking for ways to simplify and remove whole classes of bugs. EDIT: I just built lua5.4 from sources and ran my benchmarks again, and it's markedly worse than LuaJIT still, but it's better than before for sure. My conclusion is that Lua5.4 is the fastest PUC-Lua yet. https://gist.github.com/fwsGonzo/2f4518b66b147ee657d64496811f9edb https://gist.github.com/fwsGonzo/2f4518b66b147ee657d64496811...
  - anonymoushn 6y ago
    Some of these benchmarks are maybe not how one would do things if they were trying to go fast. An unfortunate idiom I wrote a thousand times at a company that uses Lua and tries to go fast is local n = 0 local t = {} -- to do an insert n = n + 1 t[n] = blorp -- to delegate some inserts to another function n = insert_some_stuff(t,n) A less messy thing you could do is local table_insert = table.insert but this is not as great, because lua will still do a binary search to find the end of the array each time you insert something.

as-j 6y ago

We chose to go with Lua on our embedded project ~2 years ago, and chose lua 5.3 with the following rational: 1. Lua embeds well on a small system and gives us a higher level language than C. lua or luajit is ok 2. Lua isn't being used for performant code. If we have performance issues use C. 3. LuaJit is looking for a maintainer and is stagnant. This isn't desirable. Not sure if this is "best practice" but it summarized how we worked through it. Lua 5.4 has some appealing benefits for us, we'll give it a few patch releases, but I look forward to moving to it. Re Performance: We're actually running from 50Hz code in Lua on an old embedded CPU. We haven't re-written that in C yet since it runs just fine. We're been constantly surprised at how well it runs and works for us.

andrewmcwatters 6y ago

If you use LuaJIT, you can generate bindings to C libraries, versus handwriting bindings for PUC Lua. The productivity difference is staggering. Additions to Lua since 5.1.5 have not helped me write more or better software, as much as I love Lua.

alexhutcheson 6y ago

LuaJIT: + Super easy FFI to C + Very fast (although profile to make sure this matters) PUC Lua: + Possible to run untrusted code (e.g. user scripts) in a sandbox + Will run on a huge variety of platforms, including many microcontrollers (only limiting factor is a C compiler and a mostly-complete libc) + Has some additional language features (although some features, including integers, are controversial) + Actively maintained, expected to receive new releases and updates

colejohnson66 6y ago
What does PUC mean in “PUC Lua”?
- deleted 6y ago
  [deleted]
- riidom 6y ago
  https://en.wikipedia.org/wiki/Pontifical_Catholic_University_of_Rio_de_Janeiro https://en.wikipedia.org/wiki/Pontifical_Catholic_University...
- alexhutcheson 6y ago
  PUC-Rio[1] which is the university where the original authors and current maintainers work. See "Where does Lua come from?" here: https://www.lua.org/about.html https://www.lua.org/about.html [1] https://www.puc-rio.br/english/ https://www.puc-rio.br/english/