6 ms·

If the difference in speed comes down to money, as the first two answers suggest, then why is LuaJIT even faster than V8? I'm pretty sure PyPy has had far more

If the difference in speed comes down to money, as the first two answers suggest, then why is LuaJIT even faster than V8? I'm pretty sure PyPy has had far more money invested in it than LuaJIT has.

mseri 12y ago
Because LUA is much simpler, already porting LUJit to LUA5.3 is revealing hard as far as I understood
- ufo 12y ago
  LuaJIT "forked" from Lua during the 5.1 days. There are still some features from 5.1 that Mike (intentionally) didn't port to LuaJIT.
- yoklov 12y ago
  My understanding is that LuaJIT isn't really under active development anymore. It does seem like it would be hard to add the 5.3 features to LuaJIT without compromising on efficiency, but given how clever Mike Pall is, I'd suspect it can be done.
  - justincormack 12y ago
    It is under active development. There is the start of an arm64 port recently for example. Mike did take a break to do other stuff for a bit it seems, but its not stopped.
    - yoklov 12y ago
      Ah, the note at the top of http://luajit.org/sponsors.html http://luajit.org/sponsors.html had made me think he was not.
mythz 12y ago
Because Mike Pall is a genius and likes working on LuaJIT so doesn't take much to sponsor him to work on it: http://luajit.org/sponsors.html http://luajit.org/sponsors.html
kephra 12y ago
Lua itself is much faster then Python or Ruby. Both languages look, as if the author did read 'A little Smalltalk' by Timothy Budd, though that its easy to design a new language, and repeated all errors(simplifications) out of the book. I dont know the main problem of Ruby, but I would point to the garbage collector for Python, as a ref counting GC is required for finalization, and ref counting is slow as hell. Python after 2.0 therefore required two slow GCs. The old ref counting GC, that slows down every object access, and in addition a simple stop the world GC to clean up cyclic references.

If the difference in speed comes down to money, as the first two answers suggest, then why is LuaJIT even faster than V8? I'm pretty sure PyPy has had far more money invested in it than LuaJIT has.

mseri 12y ago

Because LUA is much simpler, already porting LUJit to LUA5.3 is revealing hard as far as I understood

ufo 12y ago
LuaJIT "forked" from Lua during the 5.1 days. There are still some features from 5.1 that Mike (intentionally) didn't port to LuaJIT.
yoklov 12y ago
My understanding is that LuaJIT isn't really under active development anymore. It does seem like it would be hard to add the 5.3 features to LuaJIT without compromising on efficiency, but given how clever Mike Pall is, I'd suspect it can be done.
- justincormack 12y ago
  It is under active development. There is the start of an arm64 port recently for example. Mike did take a break to do other stuff for a bit it seems, but its not stopped.
  - yoklov 12y ago
    Ah, the note at the top of http://luajit.org/sponsors.html http://luajit.org/sponsors.html had made me think he was not.

mythz 12y ago

Because Mike Pall is a genius and likes working on LuaJIT so doesn't take much to sponsor him to work on it: http://luajit.org/sponsors.html http://luajit.org/sponsors.html

kephra 12y ago

Lua itself is much faster then Python or Ruby. Both languages look, as if the author did read 'A little Smalltalk' by Timothy Budd, though that its easy to design a new language, and repeated all errors(simplifications) out of the book. I dont know the main problem of Ruby, but I would point to the garbage collector for Python, as a ref counting GC is required for finalization, and ref counting is slow as hell. Python after 2.0 therefore required two slow GCs. The old ref counting GC, that slows down every object access, and in addition a simple stop the world GC to clean up cyclic references.