3 ms·

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,

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.
- meheleventyone 5y ago
  WASM SIMD support only recently started shipping in browsers as well so depending on when the GP did the benchmark it probably wasn’t used at all which is obviously a huge performance problem.

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.

meheleventyone 5y ago
WASM SIMD support only recently started shipping in browsers as well so depending on when the GP did the benchmark it probably wasn’t used at all which is obviously a huge performance problem.