From: sturlamolden on 3 Jul 2010 23: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. LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and SBCL. I know it's "just a benchmark" but this has to count as insanely impressive. Beating Intel Fortran with a dynamic scripting language, how is that even possible? And what about all those arguments that dynamic languages "have to be slow"? If this keeps up we'll need a Python to Lua bytecode compiler very soon. And LuaJIT 2 is rumoured to be much faster than the current... Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT 1.96 Java 6 -server 2.13 Intel Fortran 2.18 OCaml 3.41 SBCL 3.66 JavaScript V8 7.57 PyPy 31.5 CPython 64.6 Perl 67.2 Ruby 1.9 71.1 The only comfort for CPython is that Ruby and Perl did even worse.
From: Steven D'Aprano on 4 Jul 2010 00:15 On Sat, 03 Jul 2010 20:30:30 -0700, sturlamolden wrote: > I know it's "just a benchmark" but this has to count as insanely > impressive. Beating Intel Fortran with a dynamic scripting language, how > is that even possible? By being clever, using Just In Time compilation as much as possible, and almost certainly using masses of memory at runtime. (The usual trade-off between space and time.) See the PyPy project, which aims to do the same thing for Python as Lua have done. Their ultimate aim is to beat the C compiler and be faster than C. So far they've got a bit to go, but they're currently about twice as fast as CPython. > And what about all those arguments that dynamic > languages "have to be slow"? They're bullshit, of course. It depends on the nature of the dynamicism. Some things are inherently slow, but not everything. Fast, tight, dynamic: pick any two. > If this keeps up we'll need a Python to Lua bytecode compiler very soon. "Need" is a bit strong. There are plenty of applications where if your code takes 0.1 millisecond to run instead of 0.001, you won't even notice. Or applications that are limited by the speed of I/O rather than the CPU. But I'm nitpicking... this is a nice result, the Lua people should be proud, and I certainly wouldn't say no to a faster Python :) [...] > The only comfort for CPython is that Ruby and Perl did even worse. It's not like this is a race, and speed is not the only thing which a language is judged by. Otherwise you'd be programming in C, not Python, right? -- Steven
From: sturlamolden on 4 Jul 2010 01:05 On 4 Jul, 06:15, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > "Need" is a bit strong. There are plenty of applications where if your > code takes 0.1 millisecond to run instead of 0.001, you won't even > notice. Or applications that are limited by the speed of I/O rather than > the CPU. > But I'm nitpicking... this is a nice result, the Lua people should be > proud, and I certainly wouldn't say no to a faster Python :) Need might be too strong, sorry. I'm not a native speaker of English :) Don't read this as a complaint about Python being too slow. I don't care about milliseconds either. But I do care about libraries like Python's standard library, wxPython, NumPy, and matplotlib. And when I need C, C++ or Fortran I know where to fint it. Nobody in the scientific community would be sad if Python was so fast that no C or Fortran would have to be written. And I am sure Google and many other users of Python would not mind either. And this is kind of a proof that it can be. Considering that Lua is to Python what C is to C++ (more or less), it means that it is possible to make Python run very fast as well. Yes the LuaJIT team should be proud. Making a scripting language run faster than Fortran on CPU-bound work is a superhuman result.
From: Rami Chowdhury on 4 Jul 2010 03:12 On Saturday 03 July 2010 20:30:30 sturlamolden wrote: > I was just looking at Debian's benchmarks. It seems LuaJIT is now (on > median) beating Intel Fortran! That's amazing! Congrats to the Lua team! > If this keeps up we'll need a Python to Lua bytecode compiler very > soon. And LuaJIT 2 is rumoured to be much faster than the current... > > Looking at median runtimes, here is what I got: [snip] > The only comfort for CPython is that Ruby and Perl did even worse. Out of curiosity, does anyone know how the Unladen Swallow version of Python does by comparison? ---- Rami Chowdhury "Given enough eyeballs, all bugs are shallow." -- Linus' Law +1-408-597-7068 / +44-7875-841-046 / +88-01819-245544
From: Stefan Behnel on 4 Jul 2010 04:03
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. So it's not actually surprising that Lua beats CPython (and the other dynamic languages) in computational benchmarks. 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. Stefan |