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

31–40 of 251 posts

Re: Pay attention to WebAssembly

#31

Post by cogman10 »

fxtentacle wrote: post #19

I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentati…

> 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 while xnnpack easily handles 200fps on CPU only.

Native TesnorFlow has GPU access, WASM does not. You are seeing the difference between all CPU and CPU + GPU.

> For everything that can be inefficient, emscripten was already good enough.

WASM is the spiritual successor to emscripten's asm.js. In fact, emscripten emits WASM [2]. It's a little strange talking about it as if it were something different.

[1] https://v8.dev/docs/wasm-compilation-pipeline

[2] https://emscripten.org/docs/compiling/WebAssembly.html

Re: Pay attention to WebAssembly

#32

Post by ducharmdev »

ramesh31 wrote: post #3

WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?

This is the question I want answered more than anything. If WASM can get these, there's no doubt that it will completely reshape the future of web development.

Re: Pay attention to WebAssembly

#33

Post by striking »

hankman86 wrote: post #28
anonporridge wrote: post #11

Earlier quoted context omitted.

Not owned by shit for brains Oracle.

Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was J…

> Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript.

They're working on this. It's a tough problem, because someone has to own the resources.

I don't think browser fragmentation is an issue for the same reason that CPU instruction set fragmentation isn't an issue: you can always compile to the lowest common denominator or ensure you are only running code segments that the target platform supports using runtime checks, just the same way we do it in native applications today.

Re: Pay attention to WebAssembly

#34

Post by squidsoup »

This article mentions inflection points, but doesn’t delve into clientside apps significantly (e.g. SPAs). How far away are we from transitioning from component based JavaScript frameworks like react, to something which compiles to wasm?

Re: Pay attention to WebAssembly

#35

Post by russtrotter »

dragonwriter wrote: post #20
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?

* 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, async)

Don't get me wrong, I'm really hoping that WASM succeeds but I'm concerned that the same set of slam dunks we thought back in 1996 don't result getting posterized (again) by DOM/JS.

Re: Pay attention to WebAssembly

#36

Post by Jasper_ »

cogman10 wrote: post #31
fxtentacle wrote: post #19

I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentati…

> 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/WebAssembly/gc/issues/254

Re: Pay attention to WebAssembly

#37

Post by dom96 »

cogman10 wrote: post #31
fxtentacle wrote: post #19

I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentati…

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

It seems strange for WASM to get a GC. Shouldn't it just expose a malloc and free call?

Re: Pay attention to WebAssembly

#38

Post by darau1 »

I've heard of webassembly replacing containerization before. As an avid abuser of gitlab-runner: does this mean I'll eventually be able to run my pipelines using webassembly instead of docker? What might this look like?

Re: Pay attention to WebAssembly

#39

Post by ducharmdev »

smitop wrote: post #14
ramesh31 wrote: post #3

WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?

> garbage collection The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag. > DOM access WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.

Assuming the GC proposal eventually reaches general availability, do you think the approach of the wasm-bindgen+web_sys crates you mention could serve as a model for garbage-collected languages wishing to serve as a replacement for JavaScript?

I know the original intention of WASM was to peacefully coexist with JavaScript, not replace it, but one can dream.

Re: Pay attention to WebAssembly

#40

Post by azakai »

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 not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.

Post reply on HN