3 ms·

All Lua5.x versions use 8-byte union plus 1-byte tag, that's 12-byte TValue (16-byte on 64bit targets). (somewhat off topic) Mike authored a cunning patch to u

by zde 10y ago

All Lua5.x versions use 8-byte union plus 1-byte tag, that's 12-byte TValue (16-byte on 64bit targets). (somewhat off topic) Mike authored a cunning patch to un-box short strings, sadly it got never mainlined. http://lua-users.org/wiki/FastStringPatch http://lua-users.org/wiki/FastStringPatch

pygy_ 10y ago
Edit, yes, v5.2 supports the NaN trick (see the comments above http://www.lua.org/source/5.2/lobject.h.html#NNMARK http://www.lua.org/source/5.2/lobject.h.html#NNMARK), but only on x86. I suppose the Lua authors wanted to avoid the memory limitations of LuaJIT on 64bits machines. ---- Original below: I thought v5.2 used NaN tagging but I may be wrong. At least the beta versions did. I misremembered that post to refer to the final version: http://lua-users.org/lists/lua-l/2011-07/msg00180.html http://lua-users.org/lists/lua-l/2011-07/msg00180.html Quoted in full: ---- Lua 5.2 beta implements the "NaN trick": it packs all Lua values into a single double value by representing non-numeric values as signaled NaNs, which are (usually) not produced by the system. This trick should work on most 32-bit machines that follow IEEE 754-2008 for double representation. However, currently it is being enabled only by predefined macro __i386__ (and similars). We would like to know what other platforms could benefit from this trick (and what macros should we check in luaconf.h). You can force the trick by compiling Lua with -DLUA_NANTRICKLE (for little endian systems) or -DLUA_NANTRICKBE (for big endian). (Of course, we would also like to know whether there are problems with this implementation.) -- Roberto ---- I also think I remember people (maybe Mike Pall) reporting perf regressions between 5.2 and 5.3 because of the cache bloat introduced by mandatory 128bits values (on 64bits systems).
- zde 10y ago
  Thanks, my bad. I didn't know they tried it in 5.2.

by zde 10y ago

pygy_ 10y ago

Edit, yes, v5.2 supports the NaN trick (see the comments above http://www.lua.org/source/5.2/lobject.h.html#NNMARK http://www.lua.org/source/5.2/lobject.h.html#NNMARK), but only on x86. I suppose the Lua authors wanted to avoid the memory limitations of LuaJIT on 64bits machines. ---- Original below: I thought v5.2 used NaN tagging but I may be wrong. At least the beta versions did. I misremembered that post to refer to the final version: http://lua-users.org/lists/lua-l/2011-07/msg00180.html http://lua-users.org/lists/lua-l/2011-07/msg00180.html Quoted in full: ---- Lua 5.2 beta implements the "NaN trick": it packs all Lua values into a single double value by representing non-numeric values as signaled NaNs, which are (usually) not produced by the system. This trick should work on most 32-bit machines that follow IEEE 754-2008 for double representation. However, currently it is being enabled only by predefined macro __i386__ (and similars). We would like to know what other platforms could benefit from this trick (and what macros should we check in luaconf.h). You can force the trick by compiling Lua with -DLUA_NANTRICKLE (for little endian systems) or -DLUA_NANTRICKBE (for big endian). (Of course, we would also like to know whether there are problems with this implementation.) -- Roberto ---- I also think I remember people (maybe Mike Pall) reporting perf regressions between 5.2 and 5.3 because of the cache bloat introduced by mandatory 128bits values (on 64bits systems).

zde 10y ago
Thanks, my bad. I didn't know they tried it in 5.2.