3 ms·

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

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.

hutzlibu 5y ago
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
flohofwoe 5y ago
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) ;)
city41 5y ago
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.
cpleppert 5y ago
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.
throwaway894345 5y ago
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.
bzbarsky 5y ago
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.

hutzlibu 5y ago

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

flohofwoe 5y ago

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

city41 5y ago

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.

cpleppert 5y ago

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.

throwaway894345 5y ago

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.

bzbarsky 5y ago

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.