3 ms·

Sadly though a huge Lua fan I tend to ignore any advancements not also made in LuaJIT for pragmatic reasons. Full-width 64bit integers would be very nice but Lu

by ludamad 12y ago

Sadly though a huge Lua fan I tend to ignore any advancements not also made in LuaJIT for pragmatic reasons. Full-width 64bit integers would be very nice but LuaJIT cannot do them sadly without boxing or widening its current 64bit tagged value approach. I'd still like if LuaJIT implemented boxed 64bit integers that worked properly with its tables (eg by interning the integers, currently box identity comparisons for table lookup are awful).

sitkack 12y ago
I think having a world class JIT is somewhat of a distraction for regular Lua which is a world class language with an excellent interpreter. Lua literally runs everywhere with implementations that run in or on any platform you are currently using (Java, C#, C/C++, Javascript).
- ludamad 12y ago
  It's nice to develop code with the possibility of plugging in LuaJIT though, and the language is indeed excellent - so much in fact that I can do with ignoring post 5.1 features
acqq 12y ago
I can't imagine that Mike Pall won't find a way to make LuaJit fast with the current Lua features, together with full 64-bit integers. Can you please elaborate (or give some link)?
- nickik 12y ago
  He can if course make it fast, even very fast but conceptually its hard because he has focused so much work on making floating fast. He uses them as the basic element on the stack and hiddes pointers in the NaN. Ints dont have NaNs so that approche does not scale that well to more primitives. There are a range of compiler tricks that can make boxed math go fast as well.
- haberman 12y ago
  I asked Mike about this a while ago. Here's what he said about the challenges of it (this was a year ago, so I don't know if this represents his current thinking or not): "Using 64 bit integers all-over will definitely hurt tight loops on 32 bit machines -- narrowing number ranges is very tricky for the compiler. Also, the fact that int64_t is neither a subset nor a superset of a double is worrying. This kills various optimizations and may give surprising results even in simple mixed-type expressions."
pierrec 12y ago
I'm a bit late to the party, but isn't development of new LuaJIT features pretty much halted? The notice on [1] saying that Mike Pall cannot accept new sponsorships for the project was added one month after the last LuaJIT release. Since then, he's still made many commits [2], but they're all bugfixes (along with a couple of contributed enhancements). [1] http://wiki.luajit.org/Open-Sponsorships http://wiki.luajit.org/Open-Sponsorships [2] http://repo.or.cz/w/luajit-2.0.git/shortlog http://repo.or.cz/w/luajit-2.0.git/shortlog

by ludamad 12y ago

sitkack 12y ago

I think having a world class JIT is somewhat of a distraction for regular Lua which is a world class language with an excellent interpreter. Lua literally runs everywhere with implementations that run in or on any platform you are currently using (Java, C#, C/C++, Javascript).

ludamad 12y ago
It's nice to develop code with the possibility of plugging in LuaJIT though, and the language is indeed excellent - so much in fact that I can do with ignoring post 5.1 features

acqq 12y ago

I can't imagine that Mike Pall won't find a way to make LuaJit fast with the current Lua features, together with full 64-bit integers. Can you please elaborate (or give some link)?

nickik 12y ago
He can if course make it fast, even very fast but conceptually its hard because he has focused so much work on making floating fast. He uses them as the basic element on the stack and hiddes pointers in the NaN. Ints dont have NaNs so that approche does not scale that well to more primitives. There are a range of compiler tricks that can make boxed math go fast as well.
haberman 12y ago
I asked Mike about this a while ago. Here's what he said about the challenges of it (this was a year ago, so I don't know if this represents his current thinking or not): "Using 64 bit integers all-over will definitely hurt tight loops on 32 bit machines -- narrowing number ranges is very tricky for the compiler. Also, the fact that int64_t is neither a subset nor a superset of a double is worrying. This kills various optimizations and may give surprising results even in simple mixed-type expressions."

pierrec 12y ago

I'm a bit late to the party, but isn't development of new LuaJIT features pretty much halted? The notice on [1] saying that Mike Pall cannot accept new sponsorships for the project was added one month after the last LuaJIT release. Since then, he's still made many commits [2], but they're all bugfixes (along with a couple of contributed enhancements). [1] http://wiki.luajit.org/Open-Sponsorships http://wiki.luajit.org/Open-Sponsorships [2] http://repo.or.cz/w/luajit-2.0.git/shortlog http://repo.or.cz/w/luajit-2.0.git/shortlog