Faster NumPy in the Browser

bern4444 2 days ago |

There is also numpy-ts[1] which is measured to be faster than numpy proper if you want to skip the webassembly.

[1] https://numpyts.dev/latest/performance/overview

miohtama 3 days ago |

Wouldn't AI rewrite of these legacy Fortran packages like BLAS be easier at this point than trying to keep Fortran alive?

Jaxan 3 days ago | |

Wouldn’t it be just as easy to keep Fortran alive with ai?

miohtama 3 days ago | | |

But why would anyone want to keep Fortran alive?

cma 3 days ago | | |

Packages like BLAS

imurray 3 days ago | | |

The reference implementation of BLAS is in Fortran, but these days fast implementations (using the same interface) tend not to be. OpenBLAS is in C and much of MKL is in C/C++. An individual widely-used package can be rewritten, much like improving a compiler, or giving it a new output, benefits lots of software all at once.

However, OpenBLAS still links to the reference LAPACK in Fortran, because it's mostly made fast by linking it to a good BLAS implementation. It could be rewritten, or converted to C with f2c. Although there's a long tail of useful but often niche Fortran software, some in Fortran 90 that f2c can't convert. Having a fortran compiler is still useful, and covers all of them at once. Potentially that compiler could compile to another language, to cover more and future platforms all at once (like f2c does). It looks like that's what's going on here, compiling fortran to wasm.

sharktheone 3 days ago |

Very cool too see. So happy we actually have SIMD in WASM

wangxiaoxiang55 3 days ago |

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.

DerThorsten 1 day ago | |

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).