3 ms·

I have mixed feelings about this. On the negative side, Mike Pall is an impressive individual who has contributed a lot to the field of JIT-compiled languages,

by catwell 11y ago

I have mixed feelings about this. On the negative side, Mike Pall is an impressive individual who has contributed a lot to the field of JIT-compiled languages, so losing him is obviously bad for the project. LuaJIT is also a hard codebase to get into, I myself tried to get into it and gave up (I blogged about it last month [1]). There are probably still parts of it that only Mike understands, I guess we will see how much in the next months. On the positive side, this will forcefully increase the bus factor of the project and take it out of this situation. And maybe we will see it catch up with Lua 5.3 :) [1] http://blog.separateconcerns.com/2015-06-18-love-hate-luajit.html http://blog.separateconcerns.com/2015-06-18-love-hate-luajit...

ketralnis 11y ago
> And maybe we will see it catch up with Lua 5.3 For those that think that LuaJIT's 5.1 compatibility isn't too far behind 5.3, be aware that Lua changes a lot in its minor versions. To give you an idea, 5.2 introduced changed how scope works (both some stuff with lexical/global scope, and by redoing environments), introduced the `goto` statement, finalisers, and changed how `break` works. 5.3 introduced integers (Lua was previously like Javascript with only one Number type which was backed by a `double`), and utf8 support. This means that upgrading a Lua version can be a big deal and break all of the programs written in it. For instance, redis and WoW both still embed 5.1.
- versteegen 11y ago
  Yes, 5.3 is not a "minor version" increment, it's a major version increment on 5.2. That's how Lua version numbering works. Adding support for 5.3's integer subtype is probably going to be a very large project, I would guess that annoyed Mike. People say that LuaJIT's source is difficult to understand, but I've seen source for several VMs with JIT compilers and this one certainly isn't the gnarliest; it's decently well commented. It only took me 30 min to add a new builtin function, with almost no understanding of the codebase beyond skimming a couple header files. As long as you don't want the JIT compiler to output asm for your language extensions, it's almost friendly.
  - pygy_ 11y ago
    Parrotting Mike Pall: having 64 bits integers require 128 bits for representing Lua values. This would be bad performance-wise because it would clutter the CPU cache (as it is the case for Lua 5.3 vs 5.2). Currently, LuaJIT relies on NAN tagging which allows it to represent values in 64 bits.
    - versteegen 11y ago
      I noticed that LuaJIT has the LJ_DUALNUM define, which actually internally adds an int32 subtype which causes numbers which can fit in an int32 to be stored as such. It does not change the semantics, it's to avoid floating point ops on (mainly ARM) processors with slow or emulated FPUs. However, I think it should be possible to extend it without a huge amount of work to implement Lua 5.3 semantics with a 32 bit (rather than the default 64 bit) integer subtype. I think it would still be useful to a lot of people, personally I would love to have it. Increasing TValues to 128 bits would be very undesirable, but since luajit already supports 64 bit ints through the ffi library I don't see why they couldn't be stored as boxed udatas/cdatas in the same way.

by catwell 11y ago

ketralnis 11y ago

> And maybe we will see it catch up with Lua 5.3 For those that think that LuaJIT's 5.1 compatibility isn't too far behind 5.3, be aware that Lua changes a lot in its minor versions. To give you an idea, 5.2 introduced changed how scope works (both some stuff with lexical/global scope, and by redoing environments), introduced the `goto` statement, finalisers, and changed how `break` works. 5.3 introduced integers (Lua was previously like Javascript with only one Number type which was backed by a `double`), and utf8 support. This means that upgrading a Lua version can be a big deal and break all of the programs written in it. For instance, redis and WoW both still embed 5.1.

versteegen 11y ago
Yes, 5.3 is not a "minor version" increment, it's a major version increment on 5.2. That's how Lua version numbering works. Adding support for 5.3's integer subtype is probably going to be a very large project, I would guess that annoyed Mike. People say that LuaJIT's source is difficult to understand, but I've seen source for several VMs with JIT compilers and this one certainly isn't the gnarliest; it's decently well commented. It only took me 30 min to add a new builtin function, with almost no understanding of the codebase beyond skimming a couple header files. As long as you don't want the JIT compiler to output asm for your language extensions, it's almost friendly.
- pygy_ 11y ago
  Parrotting Mike Pall: having 64 bits integers require 128 bits for representing Lua values. This would be bad performance-wise because it would clutter the CPU cache (as it is the case for Lua 5.3 vs 5.2). Currently, LuaJIT relies on NAN tagging which allows it to represent values in 64 bits.
  - versteegen 11y ago
    I noticed that LuaJIT has the LJ_DUALNUM define, which actually internally adds an int32 subtype which causes numbers which can fit in an int32 to be stored as such. It does not change the semantics, it's to avoid floating point ops on (mainly ARM) processors with slow or emulated FPUs. However, I think it should be possible to extend it without a huge amount of work to implement Lua 5.3 semantics with a 32 bit (rather than the default 64 bit) integer subtype. I think it would still be useful to a lot of people, personally I would love to have it. Increasing TValues to 128 bits would be very undesirable, but since luajit already supports 64 bit ints through the ffi library I don't see why they couldn't be stored as boxed udatas/cdatas in the same way.