Goodbye PNaCl, Hello WebAssembly (2017)

After this gained prominence I took a hard read of Koopman's Stack Computers: The New Wave intent on writing an interpreter. I sought some optimization properties that would apply to the modern requirements for ILP, OoE and parallelization at low core frequencies -- none are offered. This manifests in WASM, and the criticism was elaborated very well: http://troubles.md/posts/wasm-is-not-a-stack-machine/

> This essentially makes WebAssembly a register machine without liveness analysis, but not only that, it’s a register machine that isn’t even in SSA form - both of the tools at our disposal to do optimisation are unavailable. In a true, optimising compiler we can recreate that information, but WebAssembly was already emitted by a compiler that generated that information once.

> ILP, OoE

Moron here, what is that in this context?

You'd like the browser to run code optimization phases?

I worked with NaCl/PNaCl in parallel to asm.js and then WASM (via Emscripten). There were pros and cons (all IMHO):

- Working with the NaCl toolchain was pretty painful compared to Emscripten. While Emscripten always tried hard to integrate as easily as possible into existing build infrastructures, NaCl was more like the Android NDK (the NIH seemed to have been pretty strong in the NaCl team).

- Likewise the integration between the Javascript side and the NaCl side: much better solved in Emscripten (especially with the ability to embed Javascript snippets into C/C++ source code, IFIR NaCl used message passing instead of being able to call directly into the JS side)

- NaCl used its own set of "system APIs" which was both good and bad, good because those APIs usually didn't have the limitations of browser APIs, bad because it was quite painful and slow to talk to browser APIs for areas that were not covered by the "builtin APIs" (and that was everything except 3D rendering, audio and networking).

- WASM still hasn't caught up with PNaCl with the "it simply works" multithreading, I'm not sure how Spectre/Meltdown would have affected NaCl though.

- The actual 'wire format differences' were always overrated, apart from a few edge cases the performance differences between asm.js, WASM, NaCl and PNaCl were quite small (the difference between NaCl and PNaCl was that NaCl was a "safe subset" of native CPU instruction sets (so you'd need different NaCl modules for running on x86 vs ARM), while PNaCl was a portable LLVM-IR derived byte code format - also once NaCl switched to PNaCl, the startup time was actually a lot slower than WASM).

All in all, my lasting impression of PNaCl is "at least it wasn't as bad as the Android NDK" ;)

You sort of can, if you don't mind piping your traffic through wireguard for example:

https://www.youtube.com/watch?v=DNS4en4JyGo