Wouldn't AI rewrite of these legacy Fortran packages like BLAS be easier at this point than trying to keep Fortran alive?
Jaxan 6 hours ago [-]
Wouldn’t it be just as easy to keep Fortran alive with ai?
miohtama 6 hours ago [-]
But why would anyone want to keep Fortran alive?
cma 4 hours ago [-]
Packages like BLAS
imurray 4 hours 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 2 hours ago [-]
Very cool too see. So happy we actually have SIMD in WASM
wangxiaoxiang55 6 hours 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.
Rendered at 14:39:17 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.