5 ms·

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

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 segmentation while xnnpack easily handles 200fps on CPU only. For everything that can be inefficient, emscripten was already good enough. For stuff that needs efficiency, Wasm is not reliable enough yet.

cogman10 5y ago
> 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 https://v8.dev/docs/wasm-compilation-pipeline [2] https://emscripten.org/docs/compiling/WebAssembly.html https://emscripten.org/docs/compiling/WebAssembly.html
- Jasper_ 5y ago
  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 https://github.com/WebAssembly/gc/issues/254
  - cogman10 5y ago
    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.
    - adrianN 5y ago
      Everyone fighting with everyone else is how every standard is made. Standards evolving slowly is generally a good thing, because it gives people time to understand each standard and learn something before the next standard is designed.
    - mrandish 5y ago
      > have been stuck in committee for years now. I've been noticing this for years too and I've concluded that a significant driver is the fact that certain major corporations (eg Apple, Google, MSFT) who sit on central web standards committees feel their app store and operating system businesses would be threatened if the full potential of Web Assembly gets in standards, implemented and widely deployed. Perhaps everything always bogging down in a way that delays or precludes fully unleashing these disruptive capabilities may not be entirely accidental. To be clear, I'm not asserting there's an intentional, pre-mediated conspiracy afoot. It's always a possibility, of course, but it's also possible that the various stakeholder business units inside these corporations are themselves conflicted, causing internal battles leading to confusion, delay and mixed signals on standards bodies. Sadly, that can end up having very much the same net effect as intentional sabotage.
    - pjmlp 5y ago
      I came to the conclusion that 3D APIs on the browsers are for ecommerce, PS2 like graphics and stuff like shader toy, specially when they have Khronos in the mix. Check this month WebGPU session, it is always the same "we hope the community will get together", "it is past MVP 1.0", "no experience with native GPGPU debugging", "you need to put up with what we have, it will improve",.... Or just make use of a middleware targeting native APIs and move on.
- dom96 5y ago
  It seems strange for WASM to get a GC. Shouldn't it just expose a malloc and free call?
  - Arnavion 5y ago
    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.
  - cogman10 5y ago
    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.
    - brabel 5y ago
      > And yes, WASM exposes malloc and free. No it doesn't. Unless you're referring to WASI, but WASI is not WASM, it's just a common API which modules can call when running on WASI-compliant WASM runtimes. All WASM itself has is linear memory, and that is not exposed via malloc/free, but via lower level instructions to set bytes on a page and grow when necessary (but not "free"). See the available instructions in the spec[1]. [1] https://www.w3.org/TR/wasm-core-1/#memory-instructions%E2%91%A0 https://www.w3.org/TR/wasm-core-1/#memory-instructions%E2%91...
- fxtentacle 5y ago
  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.
  - brrrrrm 5y ago
    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.
    - fxtentacle 5y ago
      I'm willing to believe that, but who would use a single core for an embarrassingly parallel problem such as image convolution? I'd expect it to use all 8 cores, but AFAIK, Wasm really only uses one. Probably that's the biggest performance factor then.
  - cogman10 5y ago
    > 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.
- pjmlp 5y ago
  After the political wars against PNaCL and Adobe's CrossBridge.
deleted 5y ago
[deleted]

cogman10 5y ago

> 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 https://v8.dev/docs/wasm-compilation-pipeline [2] https://emscripten.org/docs/compiling/WebAssembly.html https://emscripten.org/docs/compiling/WebAssembly.html

Jasper_ 5y ago
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 https://github.com/WebAssembly/gc/issues/254
- cogman10 5y ago
  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.
  - adrianN 5y ago
    Everyone fighting with everyone else is how every standard is made. Standards evolving slowly is generally a good thing, because it gives people time to understand each standard and learn something before the next standard is designed.
  - mrandish 5y ago
    > have been stuck in committee for years now. I've been noticing this for years too and I've concluded that a significant driver is the fact that certain major corporations (eg Apple, Google, MSFT) who sit on central web standards committees feel their app store and operating system businesses would be threatened if the full potential of Web Assembly gets in standards, implemented and widely deployed. Perhaps everything always bogging down in a way that delays or precludes fully unleashing these disruptive capabilities may not be entirely accidental. To be clear, I'm not asserting there's an intentional, pre-mediated conspiracy afoot. It's always a possibility, of course, but it's also possible that the various stakeholder business units inside these corporations are themselves conflicted, causing internal battles leading to confusion, delay and mixed signals on standards bodies. Sadly, that can end up having very much the same net effect as intentional sabotage.
  - pjmlp 5y ago
    I came to the conclusion that 3D APIs on the browsers are for ecommerce, PS2 like graphics and stuff like shader toy, specially when they have Khronos in the mix. Check this month WebGPU session, it is always the same "we hope the community will get together", "it is past MVP 1.0", "no experience with native GPGPU debugging", "you need to put up with what we have, it will improve",.... Or just make use of a middleware targeting native APIs and move on.
dom96 5y ago
It seems strange for WASM to get a GC. Shouldn't it just expose a malloc and free call?
- Arnavion 5y ago
  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.
- cogman10 5y ago
  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.
  - brabel 5y ago
    > And yes, WASM exposes malloc and free. No it doesn't. Unless you're referring to WASI, but WASI is not WASM, it's just a common API which modules can call when running on WASI-compliant WASM runtimes. All WASM itself has is linear memory, and that is not exposed via malloc/free, but via lower level instructions to set bytes on a page and grow when necessary (but not "free"). See the available instructions in the spec[1]. [1] https://www.w3.org/TR/wasm-core-1/#memory-instructions%E2%91%A0 https://www.w3.org/TR/wasm-core-1/#memory-instructions%E2%91...
fxtentacle 5y ago
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.
- brrrrrm 5y ago
  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.
  - fxtentacle 5y ago
    I'm willing to believe that, but who would use a single core for an embarrassingly parallel problem such as image convolution? I'd expect it to use all 8 cores, but AFAIK, Wasm really only uses one. Probably that's the biggest performance factor then.
- cogman10 5y ago
  > 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.
pjmlp 5y ago
After the political wars against PNaCL and Adobe's CrossBridge.

deleted 5y ago

[deleted]