Pay attention to WebAssembly

Post by codeflo » Tue, Feb 01, 2022, 7:52 AM UTC

astlouis44 wrote: post #77

hsheth2 wrote: post #75

Earlier quoted context omitted.

Thanks for the correction - I'll update my post shortly.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

Post by pjmlp » Tue, Feb 01, 2022, 7:55 AM UTC

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…

Post by pjmlp » Tue, Feb 01, 2022, 7:57 AM UTC

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…

Post by ignoramous » Tue, Feb 01, 2022, 8:01 AM UTC

fulafel wrote: post #158

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…

The only significant perf advantage WebAssembly has in browser vs JS is currently access to (Pentium II era) SIMD. This is a regrettable choice, because most languages targeting the browsers are now lacking access to SIMD. Heavier computation is currently being done with WebGL shaders (eg Google Meet background swap, TensorFlow tfjs).

Post by pjmlp » Tue, Feb 01, 2022, 8:05 AM UTC

the_duke wrote: post #134

charcircuit wrote: post #121

Earlier quoted context omitted.

>- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.

Incidentally, Minecraft Java has always had horrible performance, to the point where it was rewritten in C++. There are two versions of Minecraft now. The main reason Minecraft Java is still alive is the hackability and the resulting extensive mod ecosystem.