A lot of hopes are pinned on the future success of WebAssembly as an alternative to native apps. Of course, for this to be true WebAssembly has to be fast. But how fast is it?

WebAssembly is a strange beast. It makes use of a software stack machine and much is made of its design so as to produce the best performance. For web use this stack machine is inside the existing JavaScript engines. If you know the history of stack machines, none of this sounds promising. Despite their elegance, stack machines are not common in hardware implementations. And any code, no matter how compact and well-designed, that runs on a virtual machine or an interpreter is likely to be slow. Yet WebAssembly enthusiasts claim that it is only a bit slower then native code. On Chrome's V8 engine it runs 34% faster than the same code compiled to asm.js - a reduced form of JavaScript that can be better optimized. It also gets within 10% of native execution on a range of benchmarks and 2x slower is a reasonable worse case upper bound.

A new study from Abhinav Jangda, Bobby Powers, Arjun Guha and Emery Berger of the PLASMA lab at University of Massachusetts Amherst, however, points out that the existing benchmarks are unrealistic. They involve small test pieces of about 100 lines of code. The problem is that well-known benchmarks can't easily be run in a browser that doesn't support all of the facilities they need. The clever idea in the paper is to make use of BROWSIX, a framework which enables Unix apps to be run in the browser. The problem is that BROWSIX is written in JavaScript, not WebAssembly. The researchers solved the problem in the obvious way by creating BROWSIX-WASM, i.e. a WebAssembly version.

Armed with this new framework it was possible to run the well-known SPEC CPU benchmark. The findings confirm that WebAssembly is 30% faster than JavaScript on average. What is more surprising, is that on Firefox is is 50% slower and on Chrome 90% slower on average. It looks as if the worst case upper bound is more like the average case.

The reason for the loss of performance seems to be the way that the code is structured to use twice the number of loads and stores than equivalent native code. The researchers attribute this to the lack of registers and not making use of a wider range of x86 addressing modes. There is also the issue of larger code size, resulting in more L1 cache misses. Finally the cost of making code safe results in additional operations.

OK, this isn't really good news, but you have to remember that WebAssembly is in its infancy and this sort of information should enable implementers to improve efficiency. It might just be that WebAssembly isn't fast now, but it might be in the future. Another interesting finding is that Chrome is about 27% slower than Firefox, so providing evidence that implementation matters.

More Information

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

Abhinav Jangda, Bobby Powers, Arjun Guha, Emery Berger

Related Articles

Mozilla Makes WebAssembly For The Rest Of Us

WebAssembly Explorer - A Learning Tool

WebAssembly Is Ready For Use

WebAssemby Another Milestone 

WebAssembly Takes A Big Step Towards Being Real 

Progress On WebAssembly 

WebAssembly Has Mozilla, Microsoft,Apple and Google Backing It 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info