Lua is faster than Fortran???

[David Cournapeau]

On Sun, Jul 4, 2010 at 5:03 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> sturlamolden, 04.07.2010 05:30:
>>
>> I was just looking at Debian's benchmarks. It seems LuaJIT is now (on
>> median) beating Intel Fortran!
>>
>> C (gcc) is running the benchmarks faster by less than a factor of two.
>> Consider that Lua is a dynamically typed scripting language very
>> similar to Python.
>
> Sort of. One of the major differences is the "number" type, which is (by
> default) a floating point type - there is no other type for numbers. The
> main reason why Python is slow for arithmetic computations is its integer
> type (int in Py3, int/long in Py2), which has arbitrary size and is an
> immutable object. So it needs to be reallocated on each computation. If it
> was easily mappable to a CPU integer, Python implementations could just do
> that and be fast. But its arbitrary size makes this impossible (or requires
> a noticeable overhead, at least). The floating point type is less of a
> problem, e.g. Cython safely maps that to a C double already. But the integer
> type is.

Actually, I think the main reason why Lua is much faster than other
dynamic languages is its size. The language is small. You don't list,
dict, tuples, etc... Making 50 % of python fast is "easy" (in the
sense that it has been done). I would not be surprised if it is
exponentially harder the closer you get to 100 %. Having a small
language means that the interpreter is small - small enough to be kept
in L1, which seems to matter a lot
(http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0).

If you are interested in facts and technical details (rather than mere
speculations), this thread is interesting
http://lambda-the-ultimate.org/node/3851. It has participation of
LuaJIT author, Pypy author and Brendan Eich :)


> It's also not surprising to me that a JIT compiler beats a static compiler.
> A static compiler can only see static behaviour of the code, potentially
> with an artificially constructed idea about the target data. A JIT compiler
> can see the real data that flows through the code and can optimise for that.

Although I agree that in theory, it is rather obvious that a JIT
compiler can do many things that static analysis cannot, this is the
first time it has happened in practice AFAIK. Even hotspot was not
faster than fortran and C, and it has received tons of work by people
who knew what they were doing. The only example of a dynamic language
being as fast/faster than C that I am aware of so far is Staline, the
aggressive compiler for scheme (used in signal processing in
particular).

David