[Avshalom]

Because Octane was written by Google. So it's either:

  -representative of things Google knows it's faster at
  -representative of things Google thinks should be fast and prioritizes... and is thus faster.

or a little of column A little of column b in a feedback loop.

[gsnedders]

Octane is the continuation of V8 benchmark (and contains all of the V8 benchmark tests) — V8 (the JS engine) was specifically designed to provide good performance on those tests (this is why V8 had a generational GC from launch, for example; though somewhat amusing last I checked Carakan (Opera/Presto's last JS engine) was quickest at splay, primarily a GC benchmark, despite having a very naïve GC!). The tests new in Octane don't display such a clear disparity, as V8 wasn't designed for them.

[mraleph]

hint: Splay is a benchmark that penalizes generational GCs. If you have a fast mark-sweep GC with an aggressive growth policy you are going to totally rock it.

[gsnedders]

I may slightly be showing how long it's been since I looked at Splay. :)

My memory was that originally V8 was out-performing everyone else primarily because the initial allocation (into the nursery) was way quicker than anyone else did. Or maybe it was freeing the nodes that die young?

Certainly I remember both SpiderMonkey and Carakan spending huge amounts of time on GC on Splay, and Carakan's massive speed-up came when the object representation was changed (GC actually asymptotically regressed as a result, but in almost every practical case cache-locality (and reduction of memory accesses) outweighed it).