Mind the Gap: Analyzing the Performance of WebAssembly vs. Native Code

All major web browsers now support WebAssembly, a low-level bytecode intended to serve as a compilation target for code written in languages like C and C++. A key goal of WebAssembly is performance parity with native code; previous work reports near parity, with many applications compiled to WebAssembly running on average 10% slower than native code. However, this evaluation was limited to a suite of scientific kernels, each consisting of roughly 100 lines of code. Running more substantial applications was not possible because compiling code to WebAssembly is only part of the puzzle: standard Unix APIs are not available in the web browser environment. To address this challenge, we build BROWSIX-WASM, a significant extension to BROWSIX that, for the first time, makes it possible to run unmodified WebAssembly-compiled Unix applications directly inside the browser. We then use BROWSIX-WASM to conduct the first large-scale evaluation of the performance of WebAssembly vs. native. Across the SPEC CPU suite of benchmarks, we find a substantial performance gap: applications compiled to WebAssembly run slower by an average of 50% (Firefox) to 89% (Chrome), with peak slowdowns of 2.6x (Firefox) and 3.14x (Chrome). We identify the causes of this performance degradation, some of which are due to missing optimizations and code generation issues, while others are inherent to the WebAssembly platform.

[1]  Tosiron Adegbija,et al.  A Workload Characterization of the SPEC CPU2017 Benchmark Suite , 2018, 2018 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS).

[2]  Jan Vitek,et al.  An analysis of the dynamic behavior of JavaScript programs , 2010, PLDI '10.

[3]  Alon Zakai Emscripten: an LLVM-to-JavaScript compiler , 2011, OOPSLA Companion.

[4]  Michael Franz,et al.  Linear scan register allocation on SSA form , 2010, CGO '10.

[5]  David A Chappell Understanding ActiveX and OLE , 1996 .

[6]  Reena Panda,et al.  Wait of a Decade: Did SPEC CPU 2017 Broaden the Performance Horizon? , 2018, 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA).

[7]  Lizy Kurian John,et al.  Analysis of redundancy and application balance in the SPEC CPU2006 benchmark suite , 2007, ISCA '07.

[8]  Karl Crary,et al.  From system F to typed assembly language , 1999 .

[9]  Alan Donovan,et al.  PNaCl : Portable Native Client Executables , 2022 .

[10]  Hanspeter Mössenböck,et al.  Design of the Java HotSpot#8482; client compiler for Java 6 , 2008, TACO.

[11]  Mason Chang,et al.  Trace-based just-in-time type specialization for dynamic languages , 2009, PLDI '09.

[12]  Úlfar Erlingsson,et al.  Language-independent sandboxing of just-in-time compilation and self-modifying code , 2011, PLDI '11.

[13]  Gilad Bracha,et al.  The Java Virtual Machine Specification, Java SE 8 Edition , 2013 .

[14]  John Vilk,et al.  Browsix: Bridging the Gap Between Unix and the Browser , 2017, ASPLOS.

[15]  Alon Zakai,et al.  Bringing the web up to speed with WebAssembly , 2017, PLDI.

[16]  Michael Pradel,et al.  Performance Issues and Optimizations in JavaScript: An Empirical Study , 2016, 2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE).

[17]  George C. Necula,et al.  CIL: Intermediate Language and Tools for Analysis and Transformation of C Programs , 2002, CC.

[18]  Nikolai Tillmann,et al.  SPUR: a trace-based JIT compiler for CIL , 2010, OOPSLA.

[19]  Bennet S. Yee,et al.  Native Client: A Sandbox for Portable, Untrusted x86 Native Code , 2009, 2009 30th IEEE Symposium on Security and Privacy.

[20]  Joseph Tassarotti,et al.  RockSalt: better, faster, stronger SFI for the x86 , 2012, PLDI.