5 ms·
> I was under the vague impression that all the "obvious" optimizations had already been done (i.e. JIT, and more recently, SIMD support) Aren’t threads still
by Oreb 2y ago
> I was under the vague impression that all the "obvious" optimizations had already been done (i.e. JIT, and more recently, SIMD support)
Aren’t threads still missing? That seems like a pretty major optimization, now that almost any CPU you can buy has multiple cores.
- aseipp 2y agoYes, but they're very close to being standardized and have multiple existing implementations among different browser engines and also non-browser runtimes. (Of course, I don't think the threading proposal is exactly what OP had in mind for the case of general WASM perf improvements, but you are right it is in practice a big performance barrier in the bigger scheme.)
- garaetjjte 2y agoShared memory is standardized, you can run WASM threads in the browser through web workers. WASI threads standardization is in limbo because apparently component model is very important and nobody knows how threads will interact with that.
- aseipp 2y agoYes, I should have been more explicit: the raw WASM proposal only really defines how shared memory and cross-thread atomics work where it's assumed each thread runs a wasm module (with shared memory regions that are appropriately mapped.) It does not specify how the host environment actually spawns or manages threads or what hostcalls are available for that. That said I think in the browser something like emscripten can do something akin to "use web workers with shared array buffers" to back it all up so that threading APIs roughly work, but yes, WASI currently has nothing for this.