WebAssembly | A new binary format for the web
WebAssembly: Enhancement for asm.js
At initial stage, WebAssembly is (roughly) a binary format for delivering asm.js code.
The two main advantages of such a format are as following:
- Faster loading: Especially with large code bases and mobile devices, parsing becomes a bottleneck: “On mobile, large compiled codes can easily take 20–40s just to parse” (WebAssembly FAQ). First experiments show that WebAssembly can be loaded more than 20 times faster, because the work for parsing is minimal.
WebAssembly binaries are trees
- Math.fround(x) rounds x to a 32 bit float.
- Math.imul(x,y) multiplies the two integers x and y.
The Performance critical functionality (games, video and image decoders, etc.) will be implemented via WebAssembly, either by hand-coding it or by yet-to-be-invented languages that are slightly higher-level.
External code bases, especially those in C/C++, will be easy to port to the web platform, via WebAssembly.
The initial focus is for WebAssembly to be a compilation target for C/C++. Longer term, more features supporting other languages will be added, including the ability to create garbage-collected data (currently, asm.js creates and manages its own heap).
Frequently asked questions
–>What are the changes?
Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?
There are three reasons:
- First, this is a collaborative effort, no single company goes it alone. At the moment, the following projects are involved: Firefox, Chromium, Edge and WebKit.
–>Does the web finally have a universal bytecode?
WebAssembly is not bytecode: Bytecode is linear and (usually) stack-, register- or SSA-based, it is a binary format for an abstract syntax tree (AST). Compared to bytecode, this has the following advantages:
On the other hand, WebAssembly is like bytecode in two ways:
- It eliminates the parser as a bottleneck.
–>Isn’t WebAssembly like Flash?
yes (load time) and no (execution time)
70% of the speed native C/C++ means that WebAssembly is fast where C/C++ is fast (static code) and slow where C/C++ is slow (e.g. dynamic OOP features).
The reduction of the size of executables will be less dramatic. One can already save a lot of space via minification and compression. First experiment resulted in gzipped asm.js being 1.4 times bigger than gzipped WebAssembly.
–>How do I create WebAssembly code?
The main three options are:
- Write the code manually and use the textual representation.
- Produce binary output programmatically.
- Use a compiler to compile an LLVM-based language (initially mainly C/C++) to WebAssembly.
First experiences in practice
For the Unity Game Engine, first tests were made with WebAssembly. Quoting “WebGL: WebAssembly and Feature Roadmap” by Jonas Echterhoff for the Unity Blog:
Keep visiting here for more techie stuffs 🙂
Thank you for your patience 🙂