(free to read online)
Running code fast in web browsers: PNaCl versus asm.js
The main point of the blog post “Thoughts on asm.js vs PNaCl” (by Gregg Tavares) is:
It just seems like asm.js and PNaCl are closer than people are admitting.Some of the other points he is making are more controversial, so be sure to read the comments to get the complete picture.
Comparing PNaCl and asm.js
PNaCl [1] and asm.js [2] are Google’s and Mozilla’s solutions for running code with (near-)native speed in web browsers.asm.js is a minimal solution. It being based on JavaScript give it three advantages:
- asm.js code already runs in all current JavaScript engines, albeit much slower than in an asm.js-optimized engine.
- Easy to standardize: asm.js semantics is derived from JavaScript and thus very easy to define, because it can be based on the ECMAScript specification.
- Easy to port: an asm.js implementation is based on a JavaScript engine, meaning comparatively little work is required to create one. As an aside, standardization is a requirement for portability, because it enables interoperability between ports.
That doesn’t mean that asm.js is perfect: It can certainly benefit from further performance optimizations and while the size of a file with gzipped asm.js code seems to be acceptable, processing such a file will always incur a performance penalty (gzipped or not). But asm.js is good enough for many applications: For example, Mozilla has ported the game engine Unreal Engine 3 (= lots of C++ code) to it.
It’ll be interesting to see how much PNaCl and asm.js will become cross-browser. For PNaCl, things don’t look good: no one has indicated an interest in a port. For asm.js, Google sounded like they would support it (at Google I/O). Support from other vendors is less certain.