On Sun, Jul 4, 2010 at 5:03 PM, Stefan Behnel <stefan...@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 -- http://mail.python.org/mailman/listinfo/python-list
