Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Eh, maybe that's what you need, but not what we need ;)

WASM is an exceptionally good standard compared to most other things on the web platform.

The thing about WASM performance is that WASM is fast (unless you do stupid things), but what's surprising to most people is that Javascript isn't slow either (at an absurdly high engineering and complexity cost compared to WASM though).

View on HN

What is the point of WASM if JavaScript is just as fast? After reading the article I'm not left with the impression that getting good performance out of WASM is particularly easy either. WASM has most of the performance footguns from C, requires including a lot of details and gunk, like memory layout and an allocator, that the browser compiler would probably be better off doing on its own.

a) getting the best of other ecosystems as well

b) WASM is faster today, if done right

c) be faster with WASM with ease ... in the future, after it all and mostly tooling for it, gets stable

WASM is a much better compilation target than Javascript (and at least as important: it frees Javascript from being a compilation target, instead JS can focus on being a programming language written by humans again).

I'd argue that the main point of WASM is not the performance gain, but that it opens up a fairly straightforward path to use different languages on the web (e.g. it was possible to upstream a WASM backend into LLVM, but if the Emscripten team would have tried to upstream an asm.js backend into LLVM, they'd be laughed out of the room I'm sure - and asm.js also wasn't fast without special handling by the Javascript engine either).

Also don't forget that the above blog post is mostly about "WASM isn't as fast as it should be when using AssemblyScript", which is more of a problem to solve for AssemblyScript than WASM, because when used from C it's fairly easy to get "near-native" performance.

PS: all the disadvantages you're listing (like the linear memory layout) are actually massive advantages (for instance when trying to optimize cache misses) ;)

One nice thing about wasm is you can (sometimes) bring apps to the web very quickly. I got an emulator written in C fully ported to wasm in about an hour. To be fair this particular app hit all of the sweet spots of Emscripten, and you won't get that lucky with most apps.

WASM can be faster than JS but you need a language that doesn't shoehorn a GC into the compiled binary. I'm not really sure what the author expected here. Modern managed runtimes usually give you the benefit of bump allocation in the nursery for free with a generational GC and the runtime has a lot more room to optimize the GC phase. None of this is possible without a native GC for webassembly.

This isn't WebAssembly being slow the benchmarks just show the overhead of the GC. If you are writing a computationally expensive algorithm in Rust or C++ wasm can be a lot faster but its hard to get close to native performance(i.e. running on bare metal x86/arm).

Our webassembly prototype is about 3-4x faster in raw computation(and that is targeting webassembly exclusively) but has a much higher overhead when interacting with the DOM. That is basically the limiting factor especially on mobile.

From TFA:

> I want to be very clear: Any generalized, quantitative take-away from this article would be ill-advised.

I don't think WASM and JS are "just as fast"--the author only did a couple of microbenchmarks. There are almost certainly many cases in which WASM would outperform JS, but they probably aren't going to be tight loops over an array or similar.

Note that the article only tested V8. V8 did not have the fastest WASM implementation last I checked.... Results may well differ in other engines.

Reply on news.ycombinator.com