Bringing You Up to Speed on How Compiling WebAssembly is Faster
If you're a geography buff like me (you're probably not, but one can hope), you might remember the time when you downloaded an app to get the exhilarating experience of zooming on top of a volcano, or onto an island in the middle of the Pacific, or onto the top of the Eiffel. Then do you remember when you could do these feats from the convenience of the Chrome browser? Well, then you might have just heard that now you can do it in (almost) any browser out there. For me, that's what WebAssembly brings.
In this article, I don't expect to talk much about the language (or binary code format) itself, but implications of its compilation which makes things like Google Earth on a browser possible.
What is WebAssembly?
- it is rolled out by four major browsers (Chrome, Edge, Mozilla and Safari) i.e., platform independent
- it is programming model independent
- it is hardware independent
Is WebAssembly just C on browsers?
How does it differ from existing tools?
Compiling for WebAssembly
The overall execution flow of WebAssembly has two phases. The frontend
Since WebAssembly doesn't need assumptions (such as which type certain object is) during interpretting, the compiler doesn't need to bail out and reoptimize as such errors never occur. Finally, WebAssembly also allows you to manage memory manually (it only supports manual memory management as of now, but automation is to be added as an option) which allows you to avoid expensive garbage collection.
Implementing WebAssembly compilers
WebAssembly is walking a tight rope between high performance (C world), and safety and portability (JS world). It is hard to theorize how to optimize for it, so the WebAssembly team implemented extensions in different browsers to validate that it is indeed possible to achieve the said goal.
To permit efficient use of baseline JIT compilers, WebAssembly is designed to do fast validation and ability to track registers for allocation without IR generation. This is done by careful design of WebAssembly instructions, which the pass can use to extract register information. To integrate well with optimizing JIT compilers, WebAssembly is designed to do direct-to-SSA translation (WebAssembly is not in SSA form, but offers some tools to derive an SSA form). Moreover, structured control flow makes decoding simpler.
Another key aspect in running native code in a browser is security. Sandboxing for C/C++ has required extensive code rewriting. However, WebAssembly is executed in a sandboxed environment clearly separated from the host, making it possible to provide some security guarantees. WebAssembly avoids performance overheads through sandboxing to run at near native speed with the model created by Native Client which employs static validation of x86 machine code by mandating code generators to follow certain patterns.
How good is it?
The following bar graph demonstrates how WebAssembly performs comparative to native code (running a C application). Most benchmarks are within 10% of native performance.
An article from some designers of WebAssembly suggests that WebAssembly can run at about 80% performance of native applications. The paper also reports that performance compared to the state-of-the-art mechanism to execute native programs in a browser, asm.js, is about 33.7% better.
This scatter plot illustrates WebAssembly's benefits in terms of code size. They are on average 37.5% smaller than asm.js code and 14.7% smaller than native code.
What does this mean?
Well, as I said, Google Earth on any browser. Just in case that's not enough, playing a game on a browser is going to be very similar to downloading an app and running it natively, you can share your CAD design to someone over the web and have them take a look at it without downloading the files or even having the necessary tools installed, you'll see a lot more sophisticated features in websites such as social media, all you need is a device with a browser to experience almost any service, downloading an app is not going to be the same--- why would you, when you get similar (in human perception) performance by running them on a broswer without the overhead of installing?
WebAssembly has already achieved a lot in a short span of time (3 years
since introduced in 2017). It is already supported in all major browsers
and popular development kit Emscripten offers compiling C down to
asm.js. Personally, it has already enabled running Google Earth on
any browser (what more do you need!!).
Yet, WebAssembly is in its infancy. The popular compiler toolchain, the LLVM project, has already added a backend for it and developers are adding debug tools to improve the WebAssembly eco-system.
More exciting and enabling future options to WebAssembly may include
- stream compilation: start compiling as the bytecode is being downloaded,
- shared memory concurrency: reduce synchronization by handling it efficiently on shared memory and
- SIMD: to parallelize execution by sharing instructions among data.