The dynamic-linking detail is the part I find most interesting. On PyPI, NumPy wheels vendor a BLAS snapshot, so a BLAS improvement means waiting for the next NumPy release. Here OpenBLAS is its own conda package, so a JupyterLite / notebook.link environment picks up 0.3.35 by adding a channel and nothing else changes. That's a real payoff of treating wasm32 as a conda platform instead of a wheel target.
Question for the authors: Appendix F puts 0.3.35 at roughly 0.4-0.5x of single-thread linux-64 on GEMM. How much of the remaining gap do you attribute to wasm codegen vs. the missing threads? And is a pthreads build on the roadmap at all? A lot of JupyterLite deployments are static hosting (GitHub Pages and the like) where you can't set the COOP/COEP headers SharedArrayBuffer needs, so I'd guess single-thread stays the default for a long time regardless.
Hi, emscripten-forge author/maintainer here.
There is not yet a roadmap for pthread builds on emscripten-forge, but we are experimenting a bit with pthread support atm.
Currently we are working on migrating all pkgs to emscripten 6 and also add support for wasm64 (in addition to wasm32).
wangxiaoxiang55 · · focus · HN ↗
Question for the authors: Appendix F puts 0.3.35 at roughly 0.4-0.5x of single-thread linux-64 on GEMM. How much of the remaining gap do you attribute to wasm codegen vs. the missing threads? And is a pthreads build on the roadmap at all? A lot of JupyterLite deployments are static hosting (GitHub Pages and the like) where you can't set the COOP/COEP headers SharedArrayBuffer needs, so I'd guess single-thread stays the default for a long time regardless.
DerThorsten · · focus · HN ↗