"LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall (opens in new tab)

The numbers you point to make use of http://shootout.alioth.debian.org/u32/program.php?test=pidig...

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

If you're claiming that your interpreter is faster than someone elses you can't make your test depend on a native library for the bulk of the work. That may be a valid argument for "my language is better" but it isn't an argument for my interpreter is faster than yours.

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.

Indeed, they are strikingly similar, one of the key differences being Lua's minimal/extensible dispatch. A function call, by default, involves no searching through superclasses/prototypes. This is likely a big advantage in benchmarks.

JavaScript has multiple critical blunders in its specification that offer no advantage to the programmer, but are very difficult to optimize.

They really are quite different. Here's one example: http://lambda-the-ultimate.org/node/3851#comment-57751