JetStream should have a more rational story for jitter-oriented latency tests
authorfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 10 Jun 2015 18:44:50 +0000 (18:44 +0000)
committerfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 10 Jun 2015 18:44:50 +0000 (18:44 +0000)
commit9317c4249f37f191a5c7f15c59912a25177620c9
treee326cea7315304b803c689fd653df9debda1acea
parentb5dcd20158a30d6015aab55b77bf2d3e4e6fe320
JetStream should have a more rational story for jitter-oriented latency tests
https://bugs.webkit.org/show_bug.cgi?id=145762

Reviewed by Geoffrey Garen.

JetStream has some latency tests that are meant to measure jitter.  Prior to this change, they
did this by computing the RMS.  But the RMS is a pretty bad metric.  The thing that it rewards
isn't really the thing that you'd want your browser to do.  These RMS-based tests involve taking
the geomean of the RMS of some samples and the sample average.  The lower the geomean, the better
(in the JetStream harness we then invert the scores so that higher is better, but let's ignore
that for this discussion and assume that lower is better).  Here's an example of how this can go
bad.  A browser that always computes a task in some horribly long time (say, 1000ms) but never
varies that time will perform better than a browser that usually computes the task super quickly
(say, 10ms) and sometimes just a little bit less quickly (say, 15ms).  The former browser will
have an RMS of 0 and an average of 1000.  The latter will have a RMS somewhere around 3.5 and an
average of 12.5 (assuming equal probability of 10ms and 15ms).  The geomean of (0, 1000) is 0.
The geomean of (3.5, 12.5) is 6.6.  Lower is better, so the former browser scores higher - even
though it's obviously never better to have a browser always complete a task in 1000ms when a
different browser can do it in 15ms in the worst case.

JetStream should not have this pathology.  The right way of avoiding it is to replace RMS with
some other metric of how bad things get.  A good metric is the average of the worst percentile.
The worst 1% or the worst 5% would be good things to average.  This will catch cases where the VM
jittered due to JIT or GC, but it never have the pathology that we end up giving the better score
to a VM whose best case is worst than another VM's worst case.

For now, this change uses the highest samples above the 95% percentile. I'm not yet sure if that
is the best thing - it might include too many scores that are around the best-case performance -
but it's certainly better than RMS and it might be good enough to keep. But because of that
uncertainty, I'm setting the version to be "1.1-alpha1" to indicate that we aren't ready to
release this yet.

* JetStream/Octane2/base.js:
(.this.Setup.setup.setup):
(.this.TearDown.tearDown.tearDown):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.RunSingleBenchmark):
* JetStream/Octane2/mandreel.js:
(setupMandreel):
(updateMandreelStats):
(startMandreelTimer):
(latencyMandreel):
(tearDownMandreel):
(RMSMandreel): Deleted.
* JetStream/Octane2/splay.js:
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplayTearDown):
(SplayRMS): Deleted.
* JetStream/create.rb:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@185425 268f45cc-cd09-0410-ab3c-d52691b4dbfc
12 files changed:
PerformanceTests/ChangeLog
PerformanceTests/JetStream/Octane2/base.js
PerformanceTests/JetStream/Octane2/mandreel.js
PerformanceTests/JetStream/Octane2/splay.js
PerformanceTests/JetStream/Reference.js
PerformanceTests/JetStream/create.rb
Source/JavaScriptCore/bytecode/CodeBlock.h
Source/JavaScriptCore/bytecode/DFGExitProfile.cpp
Source/JavaScriptCore/bytecode/DFGExitProfile.h
Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
Source/JavaScriptCore/runtime/Options.h
Tools/Scripts/run-jsc-benchmarks