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

51–60 of 251 posts

Re: Pay attention to WebAssembly

#51

Post by AnIdiotOnTheNet »

fancyfredbot wrote: post #5

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

> WebAssembly is full of potential.

Eh... from what I can tell from a mostly casual glance at it (enough for a half-hearted half-complete attempt at writing my own VM for it), I'd say that it is almost a good idea. A lot of the base concepts show a lot of potential, but I feel like the implementation is full design-by-committee derp. Why are there only 32 and 64 bit types? Why are there parametric instructions at all? Why is there no instruction for shrinking or freeing a memory? Why does binary format layer 0 use LEB128 instead of a fixed-width number? Just a bunch of weird stuff like that.

But I'm hardly an expert on JIT or VM implementations, so I could be way off base here.

Re: Pay attention to WebAssembly

#52

Post by maga »

azakai wrote: post #40
maga wrote: post #30

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear reg…

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, being less subject to the vicissitudes of JIT, and offers better startup performance, allows for code reusability for existing C++/Rust code, but it's not a cure-all performance solution.

Re: Pay attention to WebAssembly

#53

Post by deathanatos »

chubot wrote: post #23

Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generato…

> e.g. Protobufs are very good for C++ C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too.

Well, hilariously, when I looked at using it on a project, JSON outperformed protobuf in Python. JSON is implemented in C, Protobuf in Python, and the C decoder for a less efficient format won out.

(Now, technically, Protobuf has a C implementation, but at the time I was testing, it segfaulted reliably. Which is the problem with C…)

I also recall there were some severe problems with protobuf's ability to represent some types, but I don't remember what they are at this point. I thought it was something to do with sum types, but I'm looking at it now and it does have oneof, so IDK.

Re: Pay attention to WebAssembly

#54

Post by peterth3 »

maga wrote: post #30

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear reg…

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-...

Re: Pay attention to WebAssembly

#55

Post by brrrrrm »

fxtentacle wrote: post #44
cogman10 wrote: post #31

Earlier quoted context omitted.

> With all the jit and garbage collection Web assembly doesn't have a GC. It is currently in the works so WASM can support other languages, such as python, more natively. As for the JIT, WASM in most implementations has only 2 levels of compilation. [1] > Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation whil…

TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from. As for TensorFlow, no I deliberately compared their CPU-only Xnnpack backend against Wasm. So both didn't use the GPU. But obviously Sse3 and avx also help a lot. Emscripten is a compiler while Wasm is an execution backend. I think it makes sense to treat them as separate because…

on an M1 I think TF.js is within 2x of native XNNPACK on a single core. Since aarch64 simd width is also 128, it works out well.

Re: Pay attention to WebAssembly

#56

Post by cogman10 »

fxtentacle wrote: post #44
cogman10 wrote: post #31

Earlier quoted context omitted.

> With all the jit and garbage collection Web assembly doesn't have a GC. It is currently in the works so WASM can support other languages, such as python, more natively. As for the JIT, WASM in most implementations has only 2 levels of compilation. [1] > Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation whil…

TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from. As for TensorFlow, no I deliberately compared their CPU-only Xnnpack backend against Wasm. So both didn't use the GPU. But obviously Sse3 and avx also help a lot. Emscripten is a compiler while Wasm is an execution backend. I think it makes sense to treat them as separate because…

> TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from.

Very likely you are observing those spikes because, AFAIK (and I could be out of date here). The WASM -> JS bridge isn't a free one to cross and was likely allocating stuff onto Javascript's GC.

WASM is/was hyper isolated and sandboxed from javascript so any of the javascript APIs, such as webgl, have to jump through a moat of handshakes (similar to Java's JNI stuff).

> But obviously Sse3 and avx also help a lot.

Yeah, probably the case then. I'd have hoped that wasm would do a better job there, but then it'll depend on the browser/runtime.

Re: Pay attention to WebAssembly

#57

Post by chrismorgan »

azakai wrote: post #40
maga wrote: post #30

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear reg…

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.

Re: Pay attention to WebAssembly

#58

Post by cogman10 »

Jasper_ wrote: post #36
cogman10 wrote: post #31

Earlier quoted context omitted.

> With all the jit and garbage collection Web assembly doesn't have a GC. It is currently in the works so WASM can support other languages, such as python, more natively. As for the JIT, WASM in most implementations has only 2 levels of compilation. [1] > Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation whil…

I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful. [0] https://github.com/WebAsse…

This is the most concerning thing I have about the web in general. It feels like nothing is getting done because everyone is fighting with everyone else about everything.

I feel like WASM has just sort of rotted. It feels like so many advancements from threads to GC have been stuck in committee for years now.

I feel the same way about WebGPU. Just doesn't feel like anything is getting done when it comes to new compute standards.

Re: Pay attention to WebAssembly

#59

Post by melony »

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…

> 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.

Re: Pay attention to WebAssembly

#60

Post by maga »

peterth3 wrote: post #54
maga wrote: post #30

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear reg…

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.
Post reply on HN