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

41–50 of 251 posts

Re: Pay attention to WebAssembly

#41

Post by kccqzy »

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 answer is obviously no.

WASM itself merely provides shared memory and instructions needed in multithreaded environments like i32.atomic.rmw.cmpxchg and i32.atomic.store, but it doesn't stipulate how threads are created.

I don't blame you but lots of people confuse WASM itself with the browsers' implementation of WASM (which, among other things, decides which functions are imported into WASM and how they work). But to me, the most exciting future of WASM is outside the browser. So we must clearly delineate features of WASM from the browser-specific bits.

Re: Pay attention to WebAssembly

#43

Post by Arnavion »

darau1 wrote: post #38

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?

Your pipeline processes would be compiled to wasm, and any syscalls they make would be serviced by the wasm runtime, which can apply whatever restrictions it wants to to contain what the process can do.

If your pipeline processes are not compiled to wasm, they could alternatively be run on an ELF loader + interpreter that is compiled to wasm and functions just like in the previous paragraph. Of course that'd likely be slow, just like running CI for a foreign arch in qemu is slow.

Re: Pay attention to WebAssembly

#44

Post by fxtentacle »

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…

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 I wanted to highlight that Wasm didn't add anything for my use cases (yet).

Of course, I expect things to get better when the technology matures, but we're not there yet.

Edit: Actually, as soon as you use Wasm with the regular APIs to access the Webcam or use WebGL, they do GC again. That's why Wasm+WebGL has unreliable performance where C+GL is real-time capable.

Plus Wasm obviously can't use zero copy paths when accessing Webcam data on the GPU, whereas I can use DMA with C, UVC, and GL. Copying a 4K frame between buffer formats 2x60 times per second also adds up.

Re: Pay attention to WebAssembly

#45

Post by trhway »

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.

we did it more than 20 years ago :) A Java Applet could call directly (Java Applet -> Java DOM API and implementing it JNI of our plugin -> native XPCOM API of Mozilla including DOM API) native DOM API of the owning browser window as well as a Java application could embed Mozilla Gecko browser engine and call the native DOM API of that embedded browser:

https://www-archive.mozilla.org/projects/blackwood/dom/

Re: Pay attention to WebAssembly

#46

Post by darau1 »

Arnavion wrote: post #43
darau1 wrote: post #38

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?

Your pipeline processes would be compiled to wasm, and any syscalls they make would be serviced by the wasm runtime, which can apply whatever restrictions it wants to to contain what the process can do. If your pipeline processes are not compiled to wasm, they could alternatively be run on an ELF loader + interpreter that is compiled to wasm and functions just like in the previous paragraph. Of course that'd likely b…

That does sound promising. It makes me wonder why, though? What does WASM do that containers don't?

edit: actually no, I answered my own question in my head: I can think of some applications for WASM that docker simply can't handle at the moment. ledger-cli, for one. I've wanted to include that in a flutter application for almost two years now. WASM seems like the perfect candidate to take care of this.

Re: Pay attention to WebAssembly

#47

Post by Arnavion »

dom96 wrote: post #37
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…

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

The point of giving it a GC is to let it partake in the host environment's GC instead of bundling its own. It's based around the assumption that the host can not only do a better job (eg browser JS VMs have plenty of experience with it) but also the GC can be shared in a larger context than an individual wasm program (eg all programs in the same browser tab can use the same GC).

It's also needed for giving host objects to the wasm program since the host objects would be managed by the host GC.

Re: Pay attention to WebAssembly

#49

Post by cogman10 »

dom96 wrote: post #37
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…

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

The thought is less about WASM having a GC and more about WASM being able to leverage the runtime's GC.

The assumption is that WASM will run in something like a v8 where the it already has a GC for Javascript. So, rather than distributing a WASM executable with all the code needed to implement a GC, you'd have it rely on the inbuilt GC. As it stands, WASM is really only a good target for C/C++/Rust. Any other language with a more substantial runtime will end up blowing the byte budget.

The question about "Should WASM do this" is really all about what WASM should/could be. Is WASM going to be a universal language target? Should it support more than low level languages?

And yes, WASM exposes malloc and free.

Re: Pay attention to WebAssembly

#50

Post by labrador »

azakai wrote: post #48
labrador wrote: post #25

Why not LLVM intermediate representation (IR)? Why do we need a whole new assembly language?

See "Why not just use LLVM bitcode as a binary format?" on the Wasm website FAQ: https://webassembly.org/docs/faq/

Thank you. For a minute there I thought I asked a stupid question, but I should RTFM
Post reply on HN