> multiple times faster

This is an unsubstantiated claim. If LuaJIT was indeed multiple times faster on arbitrary code, everybody would be just running JS on something like LuaJIT in browsers :)

LuaJIT does spectacular job on loops, especially if you limit yourself to number crunching and FFI.

But if you code is polymorphic, makes heavy use of normal OOP and does not decompose into a graph of biased loops and linear traces V8 will pull ahead due to its method-compiler nature which is not susceptible to tracing pitfalls.

Here is an interesting example: there is an issue[1] "Metatable/__index specialization" in LuaJIT repository filed by Mike Pall himself, it's about adding infrastructure which would allow traces to make optimistic assumptions about metatable constness, because it would greatly improve the quality of traces produced from OOP heavy code. (Also this is precisely the limitation that is already imposed on FFI metatypes to allow JIT generate better code). The issue is still unimplemented in LuaJIT... However this is something that V8 could do for several years now, because it is extremely important for the kind of code people are writing in the real world.

[1] https://github.com/LuaJIT/LuaJIT/issues/41

To be fair it probably also helped that Lua is a simpler language and therefore easier to optimize. A tracing JIT also has an inherent downside: the infamous example of an if in an inner loop with roughly the same probability for the then and else branch.

That said LuaJIT is an impressive piece of software. Would love to know what Mike Pall is up to now.

Afaik it's so complex it can't keep up with Lua though.

> multiple times faster

You sure about that? In the alioth benchmarks, v8 wipes the floor with lua: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

That is irrelevant. On a typed and mostly static language all is 100x easier to compile too.