New year has just started and with it new resolutions to accomplish. How about learning how to use WebAssembly and get a performance boost?
This article continues a serie of articles that we are writing about performance, go and check “How to get a performance boost using Node.js native addons” and “A 1300% performance gain with Ruby time parsing optimization!” ✌️
I want to demonstrate to you today how to create and use WebAssembly modules and later on consume them from the browser as if they were js modules. In order to do so I will take the Fibonacci algorithm, which I already discussed here and I will benchmark its performance running as a normal javascript function and as a WebAssembly module.
Implementations
We are going to cover the same 3 techniques we already covered in the previous article:
- Loop
- Recursion
- Memoization
The following snippets cover those implementations in Javascript and C.
Javascript
C
I will not explain how these functions work since this post is not about that. If you want to know more about it check this or this.
A bit of history
- WebAssembly was born with the premise of creating a safe, portable and fast to load and execute format suitable for the web. WebAssembly is not a programing language, it is a compilation target which has both text and binary specs. This means that low level languages like C/C++, Rust, Swift, etc. can be compiled with a WebAssembly output. It shares the stack with javascript, that’s why it is different from things like java-applets. Also its design is a community effort, with all browser vendors working on it.
- Emscripten is a LLVM-to-JavaScript Compiler. That means that languages like C/C++ or any language that speaks LLVM can be compiled to JavaScript. It provides a set of Apis to port your code to the web, the project has been running for years and was typically used to port games to the browser. Emscripten achieves its performance outputting asm.js but recently it has integrated successfully a WebAssembly compilation target.
- ASM.js is a low-level optimized subset of Javascript, linear memory access via TypedArrays and type annotations. Again, it is not a new programing language. Any browser without asm.js support will still work when running asm.js, it will just not get the performance benefits.
As of 10–01–2017, the current status is that it works in Chrome Canary and Firefox under a feature flag and is under development in Safari. And from the V8 side, it just got enabled by default 🚀.
This video from the Chrome Dev Summit 2016 shares the current state of JavaScript and script tooling in V8, and discusses the future with WebAssembly.
Building + Loading module
Let’s take a look at how we transform our C program into wasm. To do so, I decided to go with the Standalone output which instead of returning a combination of .js and WebAssembly, will return just WebAssembly code without the system libraries included.
This approach is based on Emscripten’s side module concept. A side module makes sense here, since it is a form of dynamic library, and does not link in system libraries automatically, it is a self-contained compilation output.
$ emcc fibonacci.c -Os -s WASM=1 -s SIDE_MODULE=1 -o fibonacci.wasm
Once we have the binary we just need to load it in the browser. To do so, WebAssembly js api exposes a top level object WebAssembly which contains the methods we need to compile and instantiate the module. Here is a simple method based on Alon Zakai gist which works as generic loader:
Cool thing here is that everything happens asynchronously. First we fetch the file content and convert it into an ArrayBuffer which contains the raw binary data in a fixed length. You can’t manipulate it directly and that’s why we then pass it to WebAssembly.compile which returns a WebAssembly.Module which you can finally instantiate with WebAssembly.Instance.
Take a look into the Binary-encoding format that WebAssembly uses if you want to go deeper into that topic.
Benchmarking
Now is time to see how we can use the module and test its performance against the javascript implementation. We will use 40 as input to be consistent with what we did in our previous article:
Results (You can check a live demo here)
JS loop x 8,605,838 ops/sec ±1.17% (55 runs sampled)JS recursive x 0.65 ops/sec ±1.09% (6 runs sampled)JS memoization x 407,714 ops/sec ±0.95% (59 runs sampled)Native loop x 11,166,298 ops/sec ±1.18% (54 runs sampled)Native recursive x 2.20 ops/sec ±1.58% (10 runs sampled)Native memoization x 30,886,062 ops/sec ±1.64% (56 runs sampled)
Fastest: Native memoizationSlowest: JS recursive
Interesting facts:
- Best C implementation is 375% faster than best JS implementation.
- Fastest implementation in C is memoization while in JS is loop.
- Second fastest implementation in C is still faster than the JS faster one.
- Slowest C implementation is 338% times faster than the JS slowest one.
Conclusion
Hope you guys have enjoyed this introduction to WebAssembly and what you can do with it today. In the next article I want to cover non standalone modules, different techniques to communicate from C <->JS and Link & Dynamic Linking.
Don’t forget to check the WebAssembly Roadmap and Emscriptend Changelog to stay up to date with the latest updates as well as the Getting Started tutorial.
Happy 2017 🐣
You can follow me on Twitter or Github @zzarcon