V8 does precompilation to native code and JIT optimization, which can typically turn numerical computations into efficient, and often highly optimized, machine code. These benchmarks seem to primarily be testing algorithms which require a lot of numerical computation and can take advantage of Javascript's typed arrays, which V8 is designed specifically to optimize.

A somewhat more fair comparison would be V8 vs. PyPy, Rubinius/RuJIT, HHVM, and LuaJIT. LuaJIT and V8 would likely still come out on top due to the amount of work and sheer excellent engineering put into the compilers (and in LuaJIT's case, also the interpreter), but PyPy's performance should be a lot better than CPython's for these benchmarks.

I also imagine (though am mostly speculating) that a benchmark involving a full-stack frontend framework like Angular or Ember, with hundreds or thousands of JS objects and lots of DOM manipulation, should put V8's performance a bit closer to CPython's.

I don't think more code will be a big problem for javascript. It seems to mostly affect start up time. Look at the asm.js tests with Massive. Also think about all js projects that use anywhere from 10 000 lince of code (LOC) to 100 000 LOC. I haven't heard anyone saying that the runtime got into any problem. There is always some problems with organizing that amount of code but that is true in almost any language. And javascript is actually quite effective to write in meaning a js program is probably much shorter than the same program in Java (at least before Java 8).

http://kripken.github.io/Massive/

I just remembered that there are demos of Unreal Engine running in js with a lot of LOC and fast performance.

>>A somewhat more fair comparison…<<

Well, it would be a different comparison; and I dare say a website showing such a comparison would attract a lot of traffic, if only someone would "please take the program source code and the measurement scripts and publish those measurements."

http://benchmarksgame.alioth.debian.org/play.html#languagex

> I also imagine (though am mostly speculating) that a benchmark involving a full-stack frontend framework like Angular or Ember, with hundreds or thousands of JS objects and lots of DOM manipulation, should put V8's performance a bit closer to CPython

Interesting idea! How would we make a version of the benchmark for CPython though?

You couldn't do the DOM parts, but you could compare Python dicts with Javascript objects, and compare performance when there are a lot of heap allocations and GC calls.

benchmarksgame is not a serious comparison site, it's in the name.

The comparisons they do is not of idiomatic code... for example in python they do a lot of array programming and don't use numpy (http://www.numpy.org/). So for most languages the results in there are completely meaningless.

The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money.

The performance of those programs with CPython explains the existence of numpy, and if you look you'll find that numpy programs are shown.

That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers, as that's one main use-case that people have in the browser. Take a look at the source code and tell me if that's the kind of code that you write.

> That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers

What were your thoughts on the regex-dna benchmark?

V8 is able to compile PCREs directly into efficient machine code (in some cases at least), CPython is not.

See: http://blog.chromium.org/2009/02/irregexp-google-chromes-new...

Thanks for the insight!

So it's not an objective comparison because the V8 implementation performs well? :-)

No, it's not an objective comparison because that's not the kind of code that we deal with in 90% of the cases, except when doing games, but then again plain Javascript is shitty for doing games, unless you develop in a strict subset that isn't meant for humans.

Even if it were "not the kind of code that you deal with in 90% of the cases" that would not mean it "was not an objective comparison".

It might mean it wasn't a relevant comparison for you; but if those 10% of cases were performance critical it would be very relevant.