GNU Octave が JupyterLite と出会う：いつでもどこでも計算可能に

• Xeus-Octave が新たに JupyterLite カーネルのエコシステムに加わり、ブラウザ上でそのまま GNU Octave コードを実行できるようになった
• GNU Octave は Matlab 互換のオープンソース科学計算言語であり、今回のプロジェクトではこれを WebAssembly(WASM) 環境で動作するよう移植した
• Fortran ベースのコードと BLAS/LAPACK 依存関係の問題を解決するため、LLVM Flang、Emscripten、Netlib LAPACK を組み合わせたカスタムツールチェーンを使用
• LLVM が Fortran の共通シンボル(Common Block) をまだサポートしていないため、簡易パッチで一時的に対応し、今後 LLVM 22 で正式サポート予定
• これにより JupyterLite で R に続いて Octave までサポートが拡張され、ブラウザベースの科学プログラミングエコシステム拡大に向けた重要な一歩が整った

---

Xeus-Octave と WebAssembly 移植の概要

• Xeus-Octave は ブラウザ上で GNU Octave コードを実行できる Jupyter カーネルで、emscripten-forge を通じてパッケージ化されている
  • GNU Octave は Matlab スクリプトを直接実行できる 無料・オープンソース言語
  • 今回の統合により、別途インストールなしで JupyterLite 環境ですぐに利用可能
• 以前に開発された Xeus-R-Lite と同様の方式で、Fortran コードコンパイル用ツールチェーン(LLVM Flang + Emscripten) を利用
• Octave の数学演算向け依存ライブラリとして OpenBLAS の代わりに Netlib LAPACK を選択し、ビルド互換性を向上

WebAssembly ビルド過程における技術的課題

• Fortran 共通ブロック(Common Symbol Block) のサポート問題により LLVM でビルドエラーが発生
  • LLVM v20 の Wasm ストリーマーが共通シンボルを実装しておらず、コード修正が必要だった
  • QuantStack チームと Serge Guelton の協業により LLVM に 簡易パッチを適用し、弱いシンボル(weak symbol)として処理
• 正式サポートは LLVM v22 リリースに含まれる予定で、現在パッチ適用済みの LLVM バージョンは Linux 向けに公開されている
• Octave 自体も WASM 向けに GUI 機能の無効化やFortran 関数シグネチャの統合などの修正が行われた

Xeus-Octave 統合とデモ

• ビルド完了後は、emscripten-forge レシピを追加するだけで JupyterLite で Xeus-Octave を実行可能
  • デモノートブック でリアルタイムのプロットを実演可能
• Xeus-Octave は C++ ベースの Jupyter カーネルフレームワーク Xeus 上に構築されており、ブラウザ上で Octave コマンドを実行して可視化できる

今後の計画

• 次のステップとして、Octave パッケージエコシステムを conda-forge および emscripten-forge に統合する計画
  • Octave の pkg ユーティリティをブラウザ環境向けに調整し、conda 環境内でのインストールプロセスを定義する予定
• これにより、ブラウザベースの 科学・数学向けプログラミング環境がさらに強化される見込み

主な貢献者と背景

• 主導開発者 Isabel Paredes は QuantStack 所属で、以前に R 言語と ROS フレームワークの WebAssembly 移植を担当
• Emscripten-forge は Thorsten Beier が主導し、複数の貢献者(Anutosh Bhat、Martin Renou など)が参加
• JupyterLite は Jeremy Tuloup が、Xeus は Johan Mabille を中心にメンテナンスされている
• Xeus-Octave は Giulio Girardi と Antoine Prouvost が開発

[GN⁺]

Hacker Newsの意見

• もしOctaveを初めて聞く人がいるなら、Octaveは商用ソフトウェアであるMATLABのオープンソースのほぼコピー版です。Wikipediaで詳しく見る
  • 「ほぼコピー」という表現は少し大げさです。私はオープンソースソフトウェアが好きですが、もう少し高度な作業をしようとすると、OctaveはまだMATLABに完全には追いついていないと感じます。OctaveとMATLABの違いを参照
  • Andrew Ng教授の初期の機械学習MOOCでOctaveが使われていたので、実習資料やサンプルを探すなら役に立ちます。YouTubeプレイリスト
  • 15年前に学部で数値解析の授業を受けたとき、MATLABの代わりにOctaveを使いましたが、その当時私たちがやっていた内容では言語互換性は完全にうまく合っていました
  • MATLABユーザーではありませんが、言語だけを複製してもMATLABのすべてが手に入るわけではないと感じます。MATLABはGUIベースのソフトウェアスイートであり、コーディングなしで使えるアプリも多く含まれています。公式ベンダーのサポートまで提供されます。昔はオープンソースに対して奇妙だったり信頼できなかったりする印象がありましたが、この分野も最近は急速に変わっています
  • ScilabもMATLABを模倣した別のソフトウェアですが、Octaveほど互換性ではなく、機能面により重点を置いています
• JupyterLiteを初めて聞く人向けに説明すると、これは従来のJupyter Notebook/Labと同じですが、完全にブラウザ内だけで動作します。サーバーやバックエンドは不要で、すべてがクライアント側で実行されます
  • PythonがWeb Assembly上で動くなら、かなり遅そうです
• 同じ技術（つまり「xeus-stack」xeus-stackリンク）によって、jupyterliteで実行できる言語/カーネルははるかに多様です。たとえば c++, python, R, lua, javascript などがサポートされています。試してみるなら Try Jupyter Lab または JupyterLiteドキュメント を参照してください。自分自身のデプロイをしたいなら xeus-lite-demoテンプレートrepo を活用できます
• Octaveは長年にわたって多くの学生に愛され、学部生にとって不可欠な代替手段の役割を果たしてきました。GNUが人類の発展に貢献した好例です。数値解析用として非常におすすめで、GNU-FortranやGNU-Cでの拡張も容易です。さまざまな拡張機能が一緒に提供されます。数値計算に特化したDSLです。同様にScilabもおすすめできるパッケージですが、拡張性は少なめです
• いつも感じるのは、著者が言及するさまざまな問題の中で、本当の魅力が埋もれてしまっているという点です。図表がもう少し前面に出て、次のリリース機能とその制作過程の課題がもっと強調されれば、より良いと思います
• GNU Octaveを別の言語にトランスパイルすることをずっと望んでいました。OctaveはすでにCライブラリとして埋め込み可能で、C/C++でOctaveを埋め込む方法 や 公式のスタンドアロンプログラム文書 を参照できます。GPUアクセラレーションをサポートするOpenCLパッケージもあり、OpenCLパッケージ を参照してください。残念ながら、GPUを暗黙的に活用する方式ではなく、明示的なGPU型と関数を提供する方式です。oclArray参照 が意味するのは、既存のOctaveコードをそのままGPU上で動かせる構造ではないという点です。ブラウザでもOpenCLベースのGPUアクセラレーションが実装されたら素晴らしいのですが、まだWebCLは実装段階に達しておらず、WebCL関連文書、Khronos WebCL を参照できます。現在はWebCLがWebGPUに置き換えられる流れで、WebCLをChromeで使う方法、gpuweb標準化案内、Chrome Web API文書 も参照しています。
  • 感想をあえて言うなら、業界が明らかなオープンソリューションではなく商用方式に固執するのは、利益のためだというのは明白です。ブルーLEDなど数多くのイノベーションの歴史を見ても分かります。AIのおかげで開発者の負担が少し減れば、むしろこうした明確な道を再び探求できるのではないかと期待しています。実際、技術革新のたびに開発者にはより多くの負担とより高い学習曲線が求められますが、それにもかかわらず報酬（初任給）は実質的に据え置かれています。AIによるペアプログラミングが広がれば、結果としてコード品質が落ちたり、複雑なコードベースが量産されたりするのではないかと懸念しています。
  • だからこそ代替となる方法に惹かれます。たとえばPythonで冗長に書く抽象化を、Octaveでは1行で表現できます。さらに簡潔にするならLISPのような関数型アセンブリ言語に行く必要がありますが、それはまた配列言語の構文上の利便性を放棄することでもあります。
  • 核心は、J.A.R.V.I.S./スタートレック風AIへ直結する道は、Octave/MATLABのようなDSLと、1980年代に使われていたSpreadsheets、HyperCard、Microsoft Access、FileMakerなどのビジネスロジックツールだという考えです。GPUアクセラレーションされたオープンなOctaveのようなツールが登場すれば、ソフトウェア作成の効率が高まり、AIの発展にも直接貢献するのではないかと想像しています
  • 代替的な方法、DSL、こうした話のすべてに本当に共感します。関連記事を参照