> LuaJIT is run with the JIT disabled (i.e. in bytecode interpreter mode) since I want to support platforms where JIT-compilation is disallowed. LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future.
I'm not an expert on this, but offhand I don't see anything fundamentally different between the capabilities of Lua and the capabilities of Python, Perl, Ruby, JavaScript, and other widespread scripting languages.
So why isn't there a PythonJIT, PerlJIY, RubyJIT, etc., comparable to LuaJIT?
Effectively though, Ruby/Perl are just much larger languages.
E.g. ruby has/had at least 5 different ways of controlling flow in a block between throw/catch, next/break, raise/rescue, return/implicit-return and callcc. 99% of the code uses the same small subset, but if you want to support "Ruby" you need to implement all of those.
Likewise, Perl has maybe simple semantics underneat, but the sheer amount of syntax-level elements is insane, also because of stratified version changes. e.g. did you know that declaring a variable with "local" instead of "my" makes it behave like a lisp-ish dynamic variable? I am fairly sure that does not exist in Lua.
As for python, there is PyPy, but I think the retrospective view on Unladen Swallow has some good points, basically: lack of enough interest from devs, lack of enough interest from users.
PyPy is a JIT for Python that's usually faster than the CPython interpreter, but not quite as fast as LuaJIT.
One of the reasons is that Python is a relatively more complex language with stuff like varargs or dict-unpacking that need to be considered at every call, and properties/__getattr__/__getattribute___ inserting themselves into the path for a simple field access. That might not be much worse than Lua's metatables, but the standard library makes use of those features in lots of places, so you can't really avoid them.
Additionally, IIRC LuaJIT uses hand-rolled assembly where necessary, while PyPy is written in Python and converted to C by the RPython toolchain using a process that involves abstract interpretation of the bytecode obtained by reflection on live code objects. That allows making use of all kinds of complex metaprogramming at initialization time to simplify the implementation, but the generated C code is unlikely to be maximally efficient.
One of the main reasons for python is that a huge part of the ecosystem depends on C extensions written against the reference python implementation C Api. Getting this to work with good performance with a JIT is very difficult. Pypy is just now getting to the point where most C extensions work with reasonable performance. Therefore for many python users there hasn't been much advantage from a JIT.
> I don't see anything fundamentally different between the capabilities of Lua and the capabilities of Python
I don't know much about Lua, but one of the problems with compiling Python (or even just cutting corners to speed up execution) is that it is extremely reflective. At runtime, you can inspect all the objects in the system, including the bytecode you are executing and the entire call stack. And worse, you can rewrite all of this at runtime, at will. Self-modifying code is a bit of a pain to compile.
Of course almost all Python code does not do this, but if you want to actually handle the full language, you must be prepared for all of it.
> LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked
I'm wondering if somebody knows about a good benchmark showing this? The ones I found in a cursory google search all seemed to show that for example node.js on V8 outperforms or matches the speed of LuaJIT.
EDIT: Seems like they only compared to python and ruby which explains why LuaJIT was always the fastest interpreter in their benchmark: http://wren.io/performance.html
> LuaJIT is run with the JIT disabled (i.e. in bytecode interpreter mode) since I want to support platforms where JIT-compilation is disallowed. LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future.
Looks like a nice embeddedable language.