[Rochus]

How would you explain then that LuaJIT is so much faster than CPython? Even the interpreter of LuaJIT is much faster.

> The only way to speed it up would be to change the language.

What specifically? Most of your points are not related to the language. And even current Smalltalk engines are much faster than CPython (see https://github.com/OpenSmalltalk/opensmalltalk-vm).

[jashmatthews]

Lua doesn’t have assignment as an expression. Lua 5.1 has float as the only numeric type. Lua varargs are easier to implement.

Each VM op for Python or Ruby ends up being bigger and having more branches. For Ruby this is quite painful on the numeric types. Branching, boxing and unboxing is far slower than just testing and adding floats in the LuaJIT VM.

Due assignment as an expression and things like x = foo(x, x+=1) Ruby, Python and JS all need to copy x into a new VM Register when it’s used. LuaJIT can assume locals aren’t reassigned mid statement and doesn’t need copies.

[Rochus]

> Lua doesn’t have assignment as an expression.

That's quite easy to achieve if you directly generate bytecode. See e.g. https://github.com/rochus-keller/som.

> Lua 5.1 has float as the only numeric type

It internaly differs between int and float.

> Ruby, Python and JS all need to copy x into a new VM Register when it’s used

Even the OpenSmalltalk VM is much faster than CPython, as well as V8.

[fanf2]

Lua exposes much less of its internals than Python. For example the comment you replied to mentioned stack frames which are not exposed in Lua.

[anonymoushn]

Those are exposed via the built-in debug library, including in luajit.

[fanf2]

Oh whoops yes :-)

Note that you can only look up variables by their bytecode register number, not by name.

[jashmatthews]

IIRC that uses the Lua C API which LuaJIT supports by fully restoring the interpreter state?