APIs and System Calls

WebAssembly does not define or require any APIs or system calls. The underlying platform decides which APIs are available and how they are implemented, whether as web APIs in the browser or POSIX in native environments.

On the source code level, the Emscripten toolchain prepares the API calls for the corresponding interfaces of the deployed machine. This can happen during compilation time or dynamically at run time.

JavaScript API

In future, the idea is for browsers to load WebAssembly modules automatically with the use of a separate HTML attribute (<script type="module">). At the moment, this is not working, so you are left with two possibilities. (1) If you rely on emcc, the compiler creates a JavaScript file in addition to the WASM binary file that provides the WebAssembly module, loads the WASM code, and integrates the HTML code with <script src="mymodule.js">. (2) However, if you generate the WASM module in the text representation yourself, you don't want to use the JavaScript generated by emcc. Instead, you need to download the WebAssembly code (the WASM file) manually into a buffer via JavaScript and then compile and instantiate the code as demonstrated in the example from Listings 3 and 4.

Listing 3 shows an excerpt from a program implemented in s-expressions that calculates the factorial of a given number. If you want to avoid manual typing, WebAssembly Explorer transforms the C or C++ code into the WA(S)T format.

When compiling the .wast file in the WebAssembly binary format (.wasm), the wast2wasm tool from the WABT Toolkit [24] is a big help. Typing

wast2wasm fact.wast -o fact.wasm

generates the file. The browser uses JavaScript to load this WASM file and executes the $fact() function. Listing 4 shows an excerpt from the HTML file, including the JavaScript part that integrates the WebAssembly code.

Figure 6 displays the output of the factorial in the browser console (Chrome Developer Tools). The result is 120, because the parameter in the function call to results.instance.exports.fact in Listing 4 (line 9) is 5. The JavaScript importObject exports functions from JavaScript to WAST. The s-expressions in the WebAssembly code then access this file [29].

Figure 6: The rather sparse output from Listing 4 can be admired in the browser console.

Benchmarking

In February 2017, Stefan Krause tested the performance of WebAssembly with various browsers [30] and compared them [31] with the fastest C and Java implementation of the benchmark. Depending on the browser, the performance of WebAssembly ranges between 130 and 190 percent compared with the native C implementation.

The Massive browser benchmark for WebAssembly also tests asm.js [32]. It compares four metrics:

• Main Thread Responsiveness measures browser availability (main() thread) when loading large chunks of code.
• Throughput is a typical benchmark, which measures the speed of execution.
• The Preparation test measures how much time elapses before the browser can run the code (i.e., load times).
• The Variance variable describes deviations in the framerate, which is mainly relevant for graphical applications such as games.

Compared with asm.js, WebAssembly performs better, which is attributable, among other things, to the binary format. Although asm.js delivers optimized JavaScript (gzip and minifier), the code in WebAssembly binary format is 10 to 20 percent more streamlined.

After downloading the binary code, the browsers can decode and parse it faster than with JavaScript from asm.js. In contrast to asm.js, WebAssembly is not limited to JavaScript when using and optimizing CPU features, which results in more speed advantages [33] [34].