Add JetStream to PerformanceTests
[WebKit-https.git] / PerformanceTests / JetStream / docs / JetStreamBlogPost.html
1 <h1>Introducing the JetStream benchmark suite</h1>
2
3 <p>Today we are introducing a new WebKit JavaScript benchmark test suite,
4 <a href="http://www.browserbench.org/JetStream">JetStream</a>. JetStream codifies what
5 our de facto process has been &mdash; to combine latency and throughput benchmarks with roughly
6 equal weighting, and capturing both metrics of traditional JavaScript programming styles as
7 well as new JavaScript-based technologies that have captured our imaginations. Scores on
8 JetStream are a good indicator of the performance users would see in advanced web applications
9 like games.</p>
10
11 <p>Optimizing the performance of our JavaScript engine is a high priority for the WebKit
12 project. Examples of some of the improvements we introduced in the last year include
13 <a href="https://bugs.webkit.org/show_bug.cgi?id=112839">concurrent compilation</a>,
14 <a href="https://bugs.webkit.org/show_bug.cgi?id=121074">generational GC</a>, and the
15 <a href="https://bugs.webkit.org/show_bug.cgi?id=112840">FTL JIT</a>. Engineering such
16 improvements requires focus: we try to prioritize high-impact projects over building and
17 maintaining complex optimizations that have smaller benefits.
18 Thus, we motivate performance work with
19 benchmarks that illustrate the kinds of workloads that WebKit users will likely encounter.
20 This philosophy of benchmark-driven development has long been part of WebKit.</p>
21
22 <h2>The previous state of JavaScript benchmarking</h2>
23
24 <p>As we made enhancements to the WebKit JavaScript engine, we found that no single
25 benchmark suite was entirely representative of the scenarios that we wanted to improve. We
26 like <a href="https://www.webkit.org/perf/sunspider/sunspider.html">SunSpider</a> for its
27 coverage of commonly-used language constructs and for the fact that its running time is
28 representative of the running time of code on the web, but it falls short for measuring
29 peak throughput. We like <a href="https://developers.google.com/octane/">Octane</a>, but it
30 skews too far in the other direction: it's useful for determining our engine's peak
31 throughput but isn't sensitive enough to the performance you'd be most likely to see on typical
32 web workloads. It also downplays novel JavaScript technologies like asm.js; only one of
33 Octane's 15 benchmarks was an asm.js test, and this test ignores floating point
34 performance.</p>
35
36 <p>Finding good asm.js benchmarks is difficult.  Even though
37 <a href="https://github.com/kripken/emscripten">Emscripten</a> is gaining
38 mindshare, its tests are long-running and until recently, lacked a web harness.
39 So we built our own asm.js benchmarks by using tests
40 from the <a href="http://llvm.org/">LLVM</a>
41 <a href="http://llvm.org/docs/TestingGuide.html#test-suite">test suite</a>.
42 These C and C++ tests are
43 used by LLVM developers to track performance improvements of the clang/LLVM compiler stack.
44 Emscripten itself uses LLVM to
45 generate JavaScript code. This makes the LLVM test suite particularly appropriate for testing
46 how well a JavaScript engine handles native code. Another benefit of our new tests is that they
47 are much quicker to run than the Emscripten test suite.</p>
48
49 <p>Having good JavaScript benchmarks allows us to confidently pursue ambitious improvements to
50 WebKit. For example, SunSpider guided our
51 concurrent compilation work, while the asm.js tests and Octane's throughput tests motivated
52 our work on the FTL JIT. But allowing our testing to be based on
53 a hodgepodge of these different benchmark suites has become impractical. It's
54 difficult
55 to tell contributors what they should be testing if there is no unified test suite
56 that can tell them if their change had the desired effect on performance. We want one test
57 suite that can report one score in the end, and we want this one score to be representative
58 of WebKit's future direction.</p>
59
60 <h2>Designing the new JetStream benchmark suite</h2>
61
62 <p>Different WebKit components require different approaches to measuring performance.
63 In some cases, the obvious approach works pretty well: for example, many layout and
64 rendering optimizations can be driven by measuring page load time on representative web pages.
65 But measuring the performance of a programming language implementation requires
66 more subtlety. We want to increase the benchmarks' sensitivity to core engine improvements, but
67 not so much so that we lose perspective on how those engine improvements play out in real
68 web sites. We want to minimize the opportunities for system noise to throw off our measurements,
69 but anytime a workload is inherently prone to noise, we want a benchmark to show this.
70 We want our benchmarks to represent a high-fidelity approximation of the workloads that
71 WebKit users are likely to care about.</p>
72
73 <p>JetStream combines a variety of JavaScript benchmarks, covering a variety of advanced
74 workloads and programming techniques, and reports a single score that balances them using a
75 geometric mean. Each test is run three times and scores are reported with 95% confidence
76 intervals. Each benchmark measures a distinct workload, and no single optimization technique
77 is sufficient to speed up all benchmarks. Some benchmarks demonstrate tradeoffs, and aggressive
78 or specialized optimization for one benchmark might make another benchmark slower. Demonstrating
79 trade-offs is crucial for our work. As discussed in my
80 <a href="https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/">previous post about
81 our new JIT compiler</a>, WebKit tries to dynamically adapt to workload using different
82 execution tiers. But this is never perfect. For example, while our new FTL JIT compiler
83 gives us fantastic speed-ups on peak throughput tests, it does cause slight regressions in
84 some ramp-up tests. New optimizations for advanced language runtimes often run into such
85 trade-offs, and our goal with JetStream is to have a benchmark that informs us about
86 the trade-offs that we are making.</p>
87
88 <p>JetStream includes benchmarks from the SunSpider 1.0.2 and Octane 2 JavaScript
89 benchmark suites. It also includes benchmarks from the LLVM compiler open source
90 project, compiled to JavaScript using Emscripten 1.13. It also includes a
91 benchmark based on the Apache Harmony open source project's HashMap, hand-translated to
92 JavaScript. More information about the benchmarks included in JetStream is
93 available on the <a href="http://www.browserbench.org/JetStream-1.0/in-depth.html">JetStream
94 In Depth</a> page.</p>
95
96 <p>We're excited to be introducing this new benchmark. To run it, simply visit
97 <a href="http://www.browserbench.org/JetStream/">browserbench.org/JetStream</a>. You can
98 <a href="http://bugs.webkit.org/">file bugs</a> against the benchmark using WebKit's bug
99 management system under the Tools/Tests component.</p>