ブラウザのNumPyがOpenBLASで最大64.89倍高速化
Faster NumPy in the Browser
Emscripten-forgeのNumPyパッケージがWebAssembly版OpenBLASをリンクし、np.matmulがn=1024でfloat32は約30.92倍、float64は約14.90倍高速になった。さらに実験版のOpenBLAS 0.3.35ではSIMD128カーネルとオプションのRelaxed SIMDにより、最終的にfloat32で64.89倍、float64で30.07倍に達する。FortranコンパイラFlangのwasm32対応など、長年の課題を解決した成果だ。
Without BLAS, np.matmul throughput decreases with n (naive GEMM, cache misses). With OpenBLAS 0.3.34 it increases with n.
- sharktheone
すごくクールだ。WASMで実際にSIMDが使えるようになったのは本当に嬉しい
- miohtama
BLASのようなレガシーなFortranパッケージを、Fortranを生かし続けようとするよりも、今となってはAIで書き直したほうが楽なんじゃないか？
- wangxiaoxiang55
動的リンクの話が一番興味深い。PyPIではNumPyのwheelがBLASのスナップショットを同梱しているので、BLASが改善されても次のNumPyリリースを待つ必要がある。ここではOpenBLASが独立したcondaパッケージなので、JupyterLite / notebook.linkの環境はチャンネルを追加するだけで0.3.35を取り込み、他は何も変わらない。これはwasm32をwheelのターゲットではなくcondaのプラットフォームとして扱うことの実質的な見返りだ。
著者への質問：付録Fでは0.3.35はGEMMでシングルスレッドのlinux-64のおよそ0.4〜0.5倍とされている。残りの差のうち、どれくらいをwasmのコード生成に、どれくらいをスレッド欠如に帰属させるのか？ また、pthreadsビルドはロードマップに含まれているのか？ JupyterLiteのデプロイの多くは静的ホスティング（GitHub Pagesなど）で、SharedArrayBufferに必要なCOOP/COEPヘッダを設定できないので、いずれにせよシングルスレッドが長くデフォルトであり続けると思う。