Goodbye PNaCl, Hello WebAssembly (2017) | Hacker News Reader

Goodbye PNaCl, Hello WebAssembly (2017)

blog.chromium.org

70 pointsddtaylor31 comments

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" ;)

To deviate a bit from the main thread, it is incredible how they managed to make Android NDK that bad.

On my case, when using it I sometimes even get the feeling "this used to be better with Symbian", clunky as it was.

And the time they take to create any improvements to it, it looks like NDK is a 20% project from Android team, that we should be thankfull it even exists to start with.

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?

ILP: Instruction Level Parallelism OOE: Out of Order Execution

You're not a moron. The use of acronyms (yeah, yeah, "initialisms") is bad writing unless you are 98% sure that your audience is familiar with them.

Its a comment chain on a tech site not an introductory article.

(Nothing wrong with not being familiar, i wasn't either, but it was totally reasonable for original poster to use them in context)

> Its a comment chain on a tech site not an introductory article.

Yes, but it's a tech site with a broad audience. I still think it's nicer to avoid any but the most commonly understood acronyms. It's a hard call to make but there's no harm erring on the side of caution.

Maybe I'm too prickly on this topic. In this particular case I think it's probably OK but I often see people misjudge this to the point where it's genuinely confusing for most of the audience.

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

With a JIT, the only question is which optimisations are worth the effort.

It does already. Wasm compilers in browsers do tiering and inlining.

Sadly, the compiler/software optimization for stack machines is a neglected field in computer architecture evolution.

If you are interested in this, you might find these useful.

1) Optimisation Techniques for Stack Based Architectures - Christopher Bailey

2) Investigating Opportunities for Instruction-Level Parallelism for Stack Machine Code - Shi Huibin

3) Second-Generation Stack Computer Architecture - Charles Laforest

[1] https://www-users.cs.york.ac.uk/~chrisb/main-pages/publicati...

[2] https://www-users.cs.york.ac.uk/~chrisb/main-pages/publicati...

Oh a different NaCl not the Cryptography library.

After the move to WASM you can no longer use TCP/UDP sockets in your extensions and must rely on WebSockets/WebRTC instead, which is a shame. See https://developer.chrome.com/docs/native-client/migration/ (see the "PPB_TCPSocket and PPB_UDPSocket" section).

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

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

That requires another node... I want a direct connection to the outside.

Is UDP-over-WebSocket built in to WireGuard, or is this really tunneling browser <> WS/UDP proxy <> WireGuard?

Uhh... um, that's cough looking to change sometime soon.

https://chromestatus.com/feature/6398297361088512

Part of me completely understands.

The other half is looking at this like a deer in⠀𝙎 𝙋 𝙄 𝘾 𝙔 ⠀ 𝙃 𝙀 𝘼 𝘿 𝙇 𝙄 𝙂 𝙃 𝙏 𝙎⠀and absolutely facepalming...

(half jokingly) docker in the browser when?

you might be on to something

stackblitz uses web containers

Maybe that would at least keep people from putting curl | sh in their Readme on Github.

NaCL was one of the layers of protection/isolation on App Engine runtimes.

This was one of the reasons why it took years to update even a minor point runtime update on App Engine before the so-called gen2 runtime that used gvisor as the sandbox took over.

Is WebAssembly still a thing? It seems like it didn't really take off.

People are using it pretty regularly. I wouldn't say it's like this end all be all technology that all company's are using or something. But yea it's a viable option, probably the main feature there is, if you target wasm your code will run the same on any machine that can run a modern browser.

Give it some time, wasm, webgpu/wgpu, etc will be more and more "normal". For now they are both in use, but kind of niche.

Heh, of course "it's still a thing" it's even wildly successful in that it has become "just another ISA/platform" from a programmer's point of view.

Of course it can never live up to the early unrealistic hype created by business people (mainly startups chasing after VC money I guess?), but of course this was very clear to the technical people from the very beginning.

It’s the focus of a lot of interesting experimental work, especially in the cloud. Its usefulness in the browser is slightly capped by the long download times, and the performance benefits get somewhat lost by having to message with the containing page. I still think it’s worth watching though.

Yeah it is! I've just made a game in Bevy and it compiled straight off to a 'web page' using Rust's wasm32-unknown-unknown target and wasm-bindgen to generate the bindings betweeen the wasm and js world (this is a limitation they are still working on - wasm blobs cannot directly access the DOM).

as soon as a wasm blob can directly access a webpage's DOM, you are free to use whatever language you want for your frontend, instead of JS. a pretty big deal if you ask me.

As long as the host platform running WASM on is allowing both write and execution of memory page (as needed for the JIT mechanism), this too will be a security issue of large proportion.

Time for Flash to make a comeback.

Here, have fun with it.

https://leaningtech.com/cheerpx-for-flash/

Reply on news.ycombinator.com