浏览器运行 NumPy 速度提升 64 倍
Faster NumPy in the Browser
长期以来，在浏览器中运行 NumPy 受限于缺乏加速的 BLAS，矩阵运算只能依赖低效的纯循环。这一局面已被 Emscripten-forge 打破，其通过 WebAssembly 链接了 OpenBLAS，使 np.matmul 在 float32 下速度提升约 30 倍。随着 OpenBLAS 0.3.35 的推出及 Relaxed SIMD 的引入，端到端性能更是实现了 64 倍的飞跃。这一突破不仅依赖于 Flang 编译器对 wasm32 的支持，更得益于 conda 生态在 WebAssembly 上的重构，让 SciPy、R 等科学计算工具也能在浏览器中高效运行。
运行 NumPy 意味着在没有加速 BLAS 的情况下运行它，矩阵乘法回退到普通的循环，这已经改变了。
- sharktheone
看到这个真的很酷。WASM 终于有了 SIMD，真是太让人高兴了。
- miohtama
到了这一步，用 AI 重写像 BLAS 这样的遗留 Fortran 包，难道不比努力让 Fortran 继续活下去更容易吗？
- wangxiaoxiang55
动态链接的细节是我觉得最有趣的部分。在 PyPI 上，NumPy 的 wheel 包捆绑了一个 BLAS 快照，所以一旦 BLAS 有了改进，就得等下一个 NumPy 版本发布。而在这里，OpenBLAS 是一个独立的 conda 包，因此 JupyterLite / notebook.link 环境只需添加一个 channel 就能获取 0.3.35 版本，其他什么都不用改。这正是将 wasm32 视为 conda 平台而非 wheel 目标所带来的实实在在的好处。
问作者一个问题：附录 F 显示 0.3.35 版本在 GEMM 上的性能大约是单线程 linux-64 的 0.4-0.5 倍。剩下的性能差距中，你们认为有多少是归因于 wasm 代码生成，又有多少是缺失线程导致的？pthread 版本有任何路线图吗？很多 JupyterLite 部署都是静态托管（如 GitHub Pages 等），无法设置 SharedArrayBuffer 所需的 COOP/COEP 头，所以我猜单线程模式在很长一段时间内都会是默认选项。