
"LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall - petermichaux
http://lambda-the-ultimate.org/node/3851#comment-57761
======
olliej
One question i have regarding these is how fair are the tests, a very quick
look at the tests shows for "pidigits" the lua code has the line:

require"c-gmp"(g, aux)

Implying that it is using the GNU Multiprecision Library for it's big integer
support, whereas the JS code has:

load('/home/dunham/shootout/bench/Include/javascript/biginteger.js');

Which is apparently a big integer library implemented in javascript
<http://www-cs-students.stanford.edu/~tjw/jsbn/>

In other words, in at least one of the tests a comparison is being made
between javascript and C/C++, not javascript and Lua.

~~~
mikemike
Actually reading the Lua mailing list post <http://lua-
users.org/lists/lua-l/2010-03/msg00305.html>, referenced in the linked text
might help:

> For pidigits I'm comparing the pure JS and Lua programs, not the GMP
> bindings.

I'm comparing these two:

[http://shootout.alioth.debian.org/u32/program.php?test=pidig...](http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=luajit&id=2)

[http://shootout.alioth.debian.org/u32/program.php?test=pidig...](http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=v8&id=1)

Both are written in pure Lua and JavaScript and do not use a C binding.

~~~
olliej
The numbers you point to make use of
[http://shootout.alioth.debian.org/u32/program.php?test=pidig...](http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=luajit&id=5)

Which is using GMP, so maybe that particular link needs to be updated?

------
WALoeIII
This is not an apples to apples comparison, the implemented Languages are
fundamentally different. I do think this is an inspiring factoid that shows
what is possible with a well done JIT.

Go Rubinius!

~~~
ardit33
how are they very different? Syntax aside, Lua and Javascript are actually
pretty similar. I would say they actually are close cousins.

~~~
olliej
One of the big issues is that any JS function can technically walks its own
call stack, which makes inlining very difficult, and for many of these tests
the ability to inline is actually a fairly substantial advantage.

The basic problem faced by a JS engine is that if it wants to be able to
inline a function it has to be able to either:

* Prove that it knows everything that the function may do -- in effect this means you can't inline any functions that themselves call functions, or any functions that interact with any values you can't consider constant, or identify before you enter the inlined code; or

* Have the ability to at any point in time reconstruct the call stack, and all arguments correctly.

One of these choices is exceedingly limiting in what you can do, and the other
is vastly complex.

~~~
sjs
As Mike Pall said: "None of the benchmarks make use of JavaScript's weird
corners. And all of them can (or could) be reduced to simple constructs. So I
wouldn't blame it on the language differences alone (maybe on the
implementation)."

Only the use of such a feature should trip the "do it the safe but slow way"
switch. Maybe that's not possible here though, I don't know that much about
compiler optimization.

edit: I'm not implying it's easy either, but if it's possible the V8 team has
the skills to implement it.

