5 ms·

There are so many forks of LuaJIT going on (raptorjit, luavela, moonjit, openresty's luajit 2, shine, ... The bad thing is that each one tries to fix a differen

There are so many forks of LuaJIT going on (raptorjit, luavela, moonjit, openresty's luajit 2, shine, ... The bad thing is that each one tries to fix a different issue: compatibility with new versions of the language, eliminate the 2 Gb limit, make more maintainable code, add extensions for web handling,... And then, some of them introduce new problems such as limiting the number of available platforms.

siddhesh 7y ago
FWIW, if RaptorJIT had not ripped out arm64, I would have ended up recommending replacing Luajit with RaptorJIT in Fedora and not bothered with forking moonjit.
- microcolonel 7y ago
  Indeed, I've been looking at writing a new backend (ambitious and foolish, many have tried, I know), so I was looking for the hottest fork, but RaptorJIT specifically guts most of the backends, and the other forks were not really doing anything.
  - lukego 7y ago
    RaptorJIT has a mostly finished port of the bytecode interpreter to C. That should make new arches /much/ easier to support because you don't have to hand-code a VM in asm, only write a JIT assembler backend. Check it out at https://github.com/raptorjit/raptorjit/pull/254 https://github.com/raptorjit/raptorjit/pull/254 Current status is that it passed the LuaJIT test suite but that's not 100% coverage and it doesn't call into the JIT yet.
    - microcolonel 7y ago
      What sort of performance have you been getting?
- armitron 7y ago
  Why not use the openresty fork which looks to be properly maintained?
  - siddhesh 7y ago
    That was my second fallback until a couple of months ago and in fact I did some work for openresty too for luajit. Openresty luajit2 however has a bunch of extensions that are incompatible with Lua and luajit, making it unsuitable as the stock luajit replacement. It would be possible to make those extensions conditional on build flags but the blocker there was the fact that the maintainers did not seem keen on doing releases and more importantly, moving too far away from luajit. Overall it was just simpler to start doing releases myself to fulfill a need (a more central place to maintain fixes for distributions) and then work towards a convergence.
anfractuosity 7y ago
Out of interest, which one removes the 2 GB limit? That was a reason I used the standard lua a while ago.
- leafo 7y ago
  There's a patch for LuaJIT that increases the limit. It comes pre-applied with the LuaJIT that installs with openresty. https://github.com/openresty/lua-nginx-module/issues/1019 https://github.com/openresty/lua-nginx-module/issues/1019
- fsfod 7y ago
  There is no 2GB limit if LuaJIT built in GC64 mode. It was an opt-in build time option until 13 days ago now its on default for 64 bit builds https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32aad79b7ea8ea6b78ed25 https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32...

siddhesh 7y ago

FWIW, if RaptorJIT had not ripped out arm64, I would have ended up recommending replacing Luajit with RaptorJIT in Fedora and not bothered with forking moonjit.

microcolonel 7y ago
Indeed, I've been looking at writing a new backend (ambitious and foolish, many have tried, I know), so I was looking for the hottest fork, but RaptorJIT specifically guts most of the backends, and the other forks were not really doing anything.
- lukego 7y ago
  RaptorJIT has a mostly finished port of the bytecode interpreter to C. That should make new arches /much/ easier to support because you don't have to hand-code a VM in asm, only write a JIT assembler backend. Check it out at https://github.com/raptorjit/raptorjit/pull/254 https://github.com/raptorjit/raptorjit/pull/254 Current status is that it passed the LuaJIT test suite but that's not 100% coverage and it doesn't call into the JIT yet.
  - microcolonel 7y ago
    What sort of performance have you been getting?
armitron 7y ago
Why not use the openresty fork which looks to be properly maintained?
- siddhesh 7y ago
  That was my second fallback until a couple of months ago and in fact I did some work for openresty too for luajit. Openresty luajit2 however has a bunch of extensions that are incompatible with Lua and luajit, making it unsuitable as the stock luajit replacement. It would be possible to make those extensions conditional on build flags but the blocker there was the fact that the maintainers did not seem keen on doing releases and more importantly, moving too far away from luajit. Overall it was just simpler to start doing releases myself to fulfill a need (a more central place to maintain fixes for distributions) and then work towards a convergence.

anfractuosity 7y ago

Out of interest, which one removes the 2 GB limit? That was a reason I used the standard lua a while ago.

leafo 7y ago
There's a patch for LuaJIT that increases the limit. It comes pre-applied with the LuaJIT that installs with openresty. https://github.com/openresty/lua-nginx-module/issues/1019 https://github.com/openresty/lua-nginx-module/issues/1019
fsfod 7y ago
There is no 2GB limit if LuaJIT built in GC64 mode. It was an opt-in build time option until 13 days ago now its on default for 64 bit builds https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32aad79b7ea8ea6b78ed25 https://github.com/LuaJIT/LuaJIT/commit/bd00094c3b50e193fb32...