Yeah, you are right, it is lesser used than e.g JavaScript, but tbh it also has a different target audience. You probably can build UI by using wasm. But why don't use JavaScript, which is way more comfortable and has a bigger community around it? (Unless you have some specific needs) As a web developer you don't need wasm right now. If you are doing some lower level work (like trying to run AI models/training) and you really need the performance, then wasm gets pretty interesting.
Most of the cool wasm projects I've seen in the past few months/ years were open source ports of games or emulators compiled to wasm (like Doom 3 ), which really ran very great. And my guess is that the broader development community is currently doing exactly this: they are playing around with wasm to learn for what use cases wasm could be a great fit.
(more known Wasm users are for example Figma or Google Earth. Iirc I've read that BBC is currently exploring if they can use wasm for their media players)
Accessing multithreading is limited as SharedArrayBuffer requires cross-origin isolation to mitigate Spectre. Apart from that, it works great.
Where are you getting your data on wasm usage?
It's also significantly faster than Javascript for some workloads, while still providing the ability to run untrusted/potentially insecure code in a sandbox.
* Adobe
* Microsoft
* Unity
* AutoDesk
* Zoom
* Snapchat (PlayCanvas)
* Twitch
and many others, and that's just on the C/C++ side, and just on the Web.
- https://news.ycombinator.com/item?id=22622341
The numbers I seen suggest wasm is 3-5x slower then native which isn't bad IMO. JavaScript is also 3-5x slower than native. Is JS close to native speed? I don't think you can say it about one but not the other
Wasm overhead is somewhere in the range of 50% (1.5x slower) to 14% (1.14x slower). Sources:
* https://www.usenix.org/system/files/atc19-jangda.pdf
* https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html
It is true you can find a specific benchmark where wasm is 3-5x slower, say if the original uses highly-tuned x86 SIMD or relaxed atomics (or if the wasm version has SIMD or threads turned off entirely). But in general, the overhead is much lower.
BTW, if there is a problem with the current WASM performance, it's probably SIMD.
Again, based solely on my own benchmarks, exclusively in the area I'm interested in (game-type workload, so, say, multiplying many small matrices, performing geometric tests), there is little to no speed-up from wasm-simd128 (where it is supported), whereas native code compiled from the same sources, by the same compiler, profiled on the same machine, seems to be running a bit faster when vectorized.
This guy found sqlite to be 19x slower. https://ricomariani.medium.com/wasm-sqlite-for-web-products-...
(SQLite stresses not just wasm but also other Web APIs, like storage, which might explain different results in different types of benchmarks.)
When you said I was wrong I knew right away you either never actually tested or you're talking about outside of the browser. If it wasn't clear I was talking about wasm in chrome/safari/firefox this entire time
No, I actually was talking about the browser.
And I have actually tested. You'll find my name on a bunch of public benchmark results about wasm and its predecessor asm.js, all in a Web context,
* Various benchmark posts on Mozilla Hacks: https://hacks.mozilla.org/author/azakaimozilla-com/
* The original wasm paper: https://people.mpi-sws.org/~rossberg/papers/Haas,%20Rossberg...
* The WasmBoxC post: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html
And specifically SQLite is a benchmark that I've looked at many times over the years. It's an important codebase. That's why I added it to the Emscripten benchmark suite, and why it is measured in that last link.
(Fyi, I am one of the co-creators of WebAssembly, I created Emscripten, and I have been working in the compile-stuff-to-the-Web space for over a decade.)
1. Why wasn't realloc part of the spec? When I looked at wasm and emscripten it appeared that realloc was essentially malloc+memcpy? That'd be painful when arrays are bigger than L2 or L3 cache. I think I heard arm cpu's all standardized to have virtual memory in 2005 or 2010 so I don't think arm hardware was an issue?
2. It seems like 100% of system calls would have to be implemented through javascript? Why wasn't there some things wasm implemented itself like a way to get time or rdtsc, realloc and other very common operations?
For the first see e.g. https://github.com/WebAssembly/design/issues/1397
For the second, WASI is doing that on the server, while on the Web we just haven't found a way that is better/faster than calling through JavaScript (we tried to do direct WebIDL bindings among other things).
But is this a failing of wasm or the system glue layer, that for something like sqlite/web has to go through js/browser/etc?
Yes, I understand the importance of real-life tests like this, but how one is expected to go about testing wasm performance as such other than using benchmarks that are mostly arithmetic/logic and not syscall-type code?
Depends on workload of course, but seems too pessimistic with the current state of WASM support. At least this is not what I'm seeing with the things I'm working on (graphics-related), when comparing to native builds.
See this test for example, native seems to be only 50% faster: https://old.reddit.com/r/WebAssembly/comments/vjxtv4/webasse...
Sadly, when the analyzer was written in Go, I was getting around 20-25% of the speed after compiling to WASM. I believe it is largely due to that code being very inefficient about allocations, and I think WASM doesn't like allocations/deallocations very much.
Have a look at Near protocol & Polkadot