Hacker News Reader

Comment by TekMol | Hacker News Reader

I'm still skeptical about the whole Wasm ordeal.

If you want to run code written in other languages in the browser, you could just as well compile to JavaScript.

All Wasm brings to the table is a bit of a speed improvement.

We do high performance computer vision in the browser (at 30/60 fps) that's an order of magnitude faster in WASM than JS. It simply would not be fast enough without WASM.

You could offload to WebGL/WebGPU for that.

Or you could use Wasm

WASM is slower, and the toolchain sucks for most languages.

> WASM is slower […]

Without more details on their exact use case, their algorithms, and their data movement patterns, you have no way of knowing this. Doing stuff on the GPU isn't automatically faster than doing it on the CPU.

Why does "most" matter in this case wnen you just need 1 that suits your needs?

Sure, but that's much more complex to implement, and comes with its own overhead.

Not that WASM tooling is such an example of great developer experience.

It's much easier to integrate some Wasm than it is to rearchitect your software to run on a GPU.

We do for some elements of our pipeline. WebGPU will give us more opporunity for this in the future too but right now we need broader device support unfortunately.

Interesting. Really an order of magnitude?

What types of operations are 10x faster in Wasm than in JS? Why can't the JIT compiler compile JS to the same native code as your Wasm gets compiled to?

We have tight inner loops over large numbers of pixels - in some cases optimized to the level of careful register choice and SIMD

Basically everything numerical. I have similar experience, translated some JS code to wasm - simple template matching algorithm, basically doing the same thing (looping over ArrayBuffer and computing some sums) and it was 10x faster.

It’s not a complete replacement for JS transpiling. It has some advantages for specific use cases. A couple benefits I like are:

Not having the JS GC randomly pausing your process unpredictably.

Sandboxing untrusted code, i.e. you sell a SaaS and you also want clients to be able to run untrusted plugins from a marketplace.

You can use fixed data structures like Uint8Array in JavaScript just like you can (have to?) in Wasm. Then you won't have the GC do stuff, right?

If JS had native SIMD, probably. But it doesn't, and it won't (because it's complex to do in JS, and you can just use Wasm instead), so it really can't compete because of just how much faster Wasm can be these days.

So how much faster than JS is Wasm for typical use-cases?

That's a bit of a trick question - typical use case for each is different, you don't use these interchengably, it doesn't make that much sense.

Typical use case for JS is let's say a glue between network and DOM, where it doesn't really do much, most of that work is done by the browser anyway. If you add wasm to that, you'll just add one more indirection through the wasm sandbox and it'll probably be slower in many cases, because you have to copy data.

Typical use case for Wasm is either porting existing native programs or something compute heavy. Figma uses this for the native layer, I used it for some image processing use cases or for board game solver backend. Doing that in JS is slower because JS semantics are not straightforward to optimize, even for basic numerical operations. I found something around 3-10x speedup for this kind of code is pretty common, but it depends on what it is doing - whether JS can represent the types and operations well.

It's not for lack of trying either, there was a JS SIMD proposal which got pretty far along, but then everyone came to their senses and scrapped it to focus on WASM SIMD instead.

https://github.com/tc39/ecmascript_simd

Yeah, that's what I meant by complex. But I still think/wish they should figure out a way to make SIMD accessible directly in JS.

Even if this were true, 'a bit of a speed improvement' is still huge given the amount of JS that's run in our world.

Wasm with simd can get things like physics simulation and some ML on the order of 2x faster. I'm finding it really useful.

Or let the GPU do it instead.

For physics it's in some cases way easier to implement on cpu. For ML using wasm means the model loads way faster (the user doesn't have to wait; and sometimes the performance is about the same). For some small models wasm can be faster. Mediapipe by google for instance gets better performance and better latency with their wasm model than the gpu one.

It's difficult (and ugly/foreign) to write fast JS and at some point you hit a wall. Incidentally that's why/how Wasm got created in the first place.

> If you want to run code written in other languages in the browser, you could just as well compile to JavaScript.

That's how asm.js was conceived. You can compile other languages to a subset of JS that is super JIT-friendly and performs stupidly well.

I think WASM came to be due to a desire to run that resulting code in a heavily sandboxed environment, with much more limited access to certain APIs than the rest of your JavaScript code.

Unrelated, but it's not clear to me why you're getting downvoted. Your point sounded genuine and didn't look like flamewar bait.

Same, it still feels like too much of a grift for VC monies to me.

Not a hater, though it's fun to run Doom in a browser tab... just can't see any business value in 99% of its ecosystem, especially with the drift away from web (the only niche where it made sense).

There’re fundamental libraries that can be used on the web because of wasm: imagemagick, ffmpeg, opencv, duckdb, sqlite, figma’s render engine...

Just because 95% of web apps are crud DOMs doesn’t mean such technology is not important.

Reply on news.ycombinator.com