From: sturlamolden on

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
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
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
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
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