Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

61–70 of 251 posts

Re: Pay attention to WebAssembly

#61

Post by hankman86 »

kccqzy wrote: post #41
hankman86 wrote: post #18

There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks. Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm…

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answ…

Oh, I have implemented wasm multi-threading both in-browser and on a node server. On the latter, it uses node's "Worker threads" API, which is very similar to in-browser Web workers. In either case, `SharedArrayBuffer` serves as the backing store for the (shared) `WebAssembly.Memory`. Wasmer is different and more like what WebAssembly should offer as part of the standard. Alas, that's not how wasm works in-browser.

But anyway, I think you confuse my point: the very fact that threading isn't fully covered by the core wasm programming model, but relies on a "hybrid" approach where the embedder needs to plug in those capabilities is a problem. Before wasm, I used Google's PNaCl quite heavily, which didn't suffer this problem and was fully self-contained.

Re: Pay attention to WebAssembly

#62

Post by evmar »

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine

This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library.

Source: I work on this code.

Re: Pay attention to WebAssembly

#63

Post by peterth3 »

maga wrote: post #52
azakai wrote: post #40

Earlier quoted context omitted.

At a glance, the bindings for wasm copy the data, https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185... If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things, which certainly limits where it makes sense!). If it's…

Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks. WASM is _predictively_ performant, bein…

The author isn’t saying it’s a “cure all performance solution.” The quote you copied uses cautious language like “almost always” and “results do vary.”

The author also cites real world apps that have switched to WASM and seen big performance gains (Figma and 1Password), which is much more compelling than the benchmarks you shared.

Re: Pay attention to WebAssembly

#64

Post by maga »

chrismorgan wrote: post #57
azakai wrote: post #40

Earlier quoted context omitted.

At a glance, the bindings for wasm copy the data, https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185... If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things, which certainly limits where it makes sense!). If it's…

Yeah, that repository is measuring performance of a WASM/Node.js hybrid, and not straight WASM. Interoperability costs can certainly dominate in such cases, where straight WASM can bypass much of the cost. Such a hybrid is what you want to measure often, but certainly not always, and a large part of what this article is talking about is the potential of pure WASM unshackled by Node.js.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

Re: Pay attention to WebAssembly

#65

Post by ashvardanian »

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly.

We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

Re: Pay attention to WebAssembly

#66

Post by zamadatix »

maga wrote: post #60
peterth3 wrote: post #54

Earlier quoted context omitted.

Levenstein distance with WASM is 40% faster in the benchmarks on the linked medium article. WASM (145,086 ops/sec) JavaScript (102,775 ops/sec) https://medium.com/netscape/javascript-c-modern-ways-to-use-...

And that's another thing about JavaScript engines--they evolve and usually result in better performance. The article is written in 2017 and the results are from Node.js of the time, meanwhile the results in the repository are from the last year.

Can confirm, I ran the benchmark in that repo and rather than JS being 30% faster in Levenstein distance it was ~10% slower but both had improved relative to the native score.

Re: Pay attention to WebAssembly

#67

Post by dragonwriter »

russtrotter wrote: post #35
dragonwriter wrote: post #20

Earlier quoted context omitted.

* Already in all the browsers natively, without plugins or similar third-party optional components, and * Already widely supported as a compilation target, and not just for special languages targeting the platform

To continue the Java bytecode prior comment, at one point, java was in all browsers of the time (i.e. Applets). However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. Java also enjoys multiple HLLs that target its bytecode (Scala, Kotlin, Groovy, Jython, etc) and there's nothing in the runtime capabilities that tie it to any kind of constrained platform (threading, IO,…

> To continue the Java bytecode prior comment, at one point, java was in all browsers of the time

No, it wasn't.

> (i.e. Applets).

Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser.

> However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility.

It progressively lost to (1) other plug-in based tech (Flash), and (2) expansion and optimizayiom of the web platform to make plug-in based tech less needed while security problems of the model became more visible, and finally (3) the rising importance of web browsers that didn't support plugins (which are now dominant even on desktop.)

> Java also enjoys multiple HLLs that target its bytecode

But not C/C++ (or, now, Rust/Go), in which a lot of common code on which native-targeted code in other languages rely is written. WASM was specifically designed with being a target for C/C++, and those and languages like Rust and Go already target it.

Re: Pay attention to WebAssembly

#68

Post by maga »

peterth3 wrote: post #63
maga wrote: post #52

Earlier quoted context omitted.

Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks. WASM is _predictively_ performant, bein…

The author isn’t saying it’s a “cure all performance solution.” The quote you copied uses cautious language like “almost always” and “results do vary.” The author also cites real world apps that have switched to WASM and seen big performance gains (Figma and 1Password), which is much more compelling than the benchmarks you shared.

You do realize that I didn't put up those benchmarks and wrote the article way back in 2017 just so that I can pick on a passage in this article? I was (and still am to a degree) excited about WASM, actually ported a significant chunk of my business logic from JS to C++ only to discover that the whole thing offered only ~20% performance boost, which didn't merit maintaining a whole separate toolchain. I'm not questioning the exciting results that Figma and such achieve, I'm saying that it's not "almost always" a case, and it's disingenuous to present it as such.

Re: Pay attention to WebAssembly

#69

Post by tyingq »

melony wrote: post #59
kccqzy wrote: post #41

Earlier quoted context omitted.

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answ…

> Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answer is obviously no. Yes actually. CloudFlare and several other cloud providers are trying to push towards V8 based sandboxing on the edge instead of the node-in-KVM model used by firecracker because the former is lighter and easier to deploy.

That's more of a "sort of". It is V8, but no "webworkers as threads", and then things like the cache api, cron-like scheduling, k/v store and durable objects added on.
Post reply on HN