4 ms·

No need to wonder, have a look at the source code for them both and it will become clear exactly why there is such a performance difference. Lua gives you raw

by sjs 17y ago

No need to wonder, have a look at the source code for them both and it will become clear exactly why there is such a performance difference. Lua gives you raw C numeric types which makes a big difference right there. Other people have mentioned a few other good reasons too (no costly method dispatch). I haven't looked at LuaJIT yet but considering how small it is I'm sure it meets or exceeds the quality of the code behind Lua.

chancho 17y ago
> Lua gives you raw C numeric types Standard Lua (the one from PUC-Rio) doesn't really, it uses boxed numeric values, as I imagine ruby (and almost every other dynamic language) does as well. "Boxed" meaning that each number is stored on the heap with some kind of tag, and when you pass such a value to a function you're really passing a pointer to it and that indirection costs cycles and puts pressure on the cache. LuaJIT's most significant (IMO) feature is that it stores numeric values directly, like C does, so when you call a function the actual bits representing it go right on the stack, not the address of where the bits can be found, and it uses some cool tricks of floating point representation to prevent the garbage collector from trying to follow these stack values as if they were pointers. This (combined with the trace optimization) is why when you write a numeric for-loop in LuaJIT it runs (nearly?) as fast a C.
- mascarenhas 17y ago
  Lua numbers are not boxed in the usual sense; they live in the Lua data stack (which leaves in the C heap, but this is not isomorphic to the Lua heap), are not accessed through a pointer, and do not put pressure on Lua's memory allocator and garbage collector. LuaJIT 2's NaN tagging alone does not speed up the stock interpreter: http://article.gmane.org/gmane.comp.lang.lua.general/44823 http://article.gmane.org/gmane.comp.lang.lua.general/44823.
deleted 17y ago
[deleted]

by sjs 17y ago

chancho 17y ago

> Lua gives you raw C numeric types Standard Lua (the one from PUC-Rio) doesn't really, it uses boxed numeric values, as I imagine ruby (and almost every other dynamic language) does as well. "Boxed" meaning that each number is stored on the heap with some kind of tag, and when you pass such a value to a function you're really passing a pointer to it and that indirection costs cycles and puts pressure on the cache. LuaJIT's most significant (IMO) feature is that it stores numeric values directly, like C does, so when you call a function the actual bits representing it go right on the stack, not the address of where the bits can be found, and it uses some cool tricks of floating point representation to prevent the garbage collector from trying to follow these stack values as if they were pointers. This (combined with the trace optimization) is why when you write a numeric for-loop in LuaJIT it runs (nearly?) as fast a C.

mascarenhas 17y ago
Lua numbers are not boxed in the usual sense; they live in the Lua data stack (which leaves in the C heap, but this is not isomorphic to the Lua heap), are not accessed through a pointer, and do not put pressure on Lua's memory allocator and garbage collector. LuaJIT 2's NaN tagging alone does not speed up the stock interpreter: http://article.gmane.org/gmane.comp.lang.lua.general/44823 http://article.gmane.org/gmane.comp.lang.lua.general/44823.

deleted 17y ago

[deleted]