Python 3.12向けWindowsでのSciPyビルド、小さな奇跡と評価

Python 3.12版SciPyのビルドが奇跡のような理由

• 最近、Python 3.12がリリースされた。
• 主要パッケージが新しいPythonバージョンと互換性のあるリリースをすぐに提供するのは一般的なことだ。
• SciPyがPython 3.12互換のビルドを公開できたのは、複数のタイムラインが重なった幸運な結果だった。

Fortranとコンパイラの役割

• Fortranは1950年代から重要なプログラミング言語で、多くの科学計算コードがFortranで書かれている。
• さまざまなFortranコンパイラが存在していたが、いずれも独占的だった。
• コンパイラは、プログラマが書いたコードをコンピュータが実行可能な形に変換する役割を持つ。
• GCCは自由に利用できるコンパイラで、さまざまなCPUアーキテクチャとオペレーティングシステムをサポートしている。

Pythonと性能の問題

• Pythonはコンパイラなしで使えるが、コンパイル言語に比べると遅い。
• 性能が重要な場合は、コンパイル済みコードを使いつつ、Pythonインターフェースでラップするのがよい解決策だ。
• NumPyとSciPyは性能のためにFortranコードを利用しており、そのためユーザーがパッケージをインストールする際にコンパイラが必要になる。

Pythonパッケージングの問題

• Pythonのパッケージングは複雑さゆえに、継続的に再発明されてきた。
• ソースコードを直接ダウンロードする方法では、ユーザーにコンパイラ設定が必要で、ビルド時間も長くなるといった問題がある。
• wheelフォーマットは、パッケージに必要なライブラリを含めて配布する方式として改善をもたらした。

condaとconda-forgeの登場

• condaは、パッケージングに必要なものをすべて含む、より包括的なアプローチを提供する。
• conda-forgeは、コミュニティ主導でパッケージ統合作業を行うチャネルだ。
• conda-forgeは一般的なすべてのプラットフォームをサポートしようとしており、ボランティアによって運営されている。

SciPyのビルドツールとしてのMeson採用

• SciPyはビルドツールとしてMesonを採用した。
• MesonはPython風のインターフェースを提供し、CMakeより複雑さが少ない。
• Mesonは、専門家でないユーザーに誤った作業を許さないという設計思想を持っている。

Fortranの復活とLLVM

• Fortranはここ数年で再び注目を集めている。
• LLVMベースの新しいFortranコンパイラの開発が活発化している。
• LLVMは、多様なアーキテクチャとプラットフォームで動作するコンパイラインフラを提供する。

SciPyのMeson移行とconda-forgeの問題

• SciPyはMesonへ移行したが、Windows向けFortranコンパイラの不在により問題が発生した。
• conda-forgeはPython 3.12への移行のため、関連するすべてのパッケージを再ビルドする必要があった。

「ユカタストロフィ」の意味とGN⁺の見解

• SciPyのテストスイートが100%通過し、conda-forgeでPython 3.12互換のSciPyビルドが可能になった。
• これは、さまざまな努力と偶然が重なった結果であり、Pythonコミュニティに大きな利益をもたらした。
• GN⁺の見解: この記事は、Pythonコミュニティの努力と協力がいかにして複雑な技術的問題を解決できるかを示している。SciPyがPython 3.12互換のビルドを無事に公開したことは、科学技術計算分野における重要な前進であり、これはオープンソースソフトウェアの強さとコミュニティの力を象徴している。

[GN⁺]

Hacker Newsの意見

• フリーソフトウェアコミュニティはマイクロソフトのオペレーティングシステム向けサポートを打ち切り、scipy のようなものは彼ら自身に移植させるべき

  • Linux が必要な人は WSL2 で利用できる
  • マイクロソフトは、他のすべての OS ベンダーがこの 60 年間やってきたように、コンパイラを OS に同梱すべき

• Python パッケージングが複雑なのは、C/C++/Fortran ビルドツールの非標準性と巨大なエコシステムのためであり、Python 自体の問題ではない

  • この複雑さには削減できない部分がある
  • Python パッケージングシステムが動作していること自体が奇跡

• Meson ビルドツールが MSVC+gfortran の組み合わせを拒否するのはバグに見える

  • ビルドツールの目的は、ユーザーが指示したコマンドを実行することであって、ユーザーを拒否することではない

• 多くの人が WSL2 を使って問題を解決しており、なぜネイティブ Windows 版をビルドしようとするのか気になる

• 最高の BLAS ライブラリの多くは C で書かれており、C と Python だけでもある程度の成果を出せるのではないかと気になる

  • Fortran は避けられない部分かもしれないが、Windows での Fortran ツール改善が始まっているのは前向き

• Fortran の意味論が C とあまりにも違うため、C に変換してから C コンパイラでコンパイルできないのか、そして C で保守することが可能なのかという素朴な疑問

  • 古いライブラリを保守している Fortran の専門家は多くないだろうと推測され、保守が必要

• Python のビルドシステムの変化についていくのが難しい

  • Windows での性能値には興味があるが、本格的な作業のほとんどは Linux マシンで実行されるだろうと予想される

• 「aarch64」と「arm64」は同じものなのかという質問

  • Wikipedia では ARM64 が AArch64 にリダイレクトされる

• Fortran は IT 部門で冗談の対象だったが、ここ数年で劇的な復活を遂げている

  • この復活の理由は明確ではないが、関連リンクを通じて理解できる

• コンパイラ/アーキテクチャ表における「arm64」と「aarch64」の違いについての質問

  • Wikipedia の ARM64 記事が AArch64 にリダイレクトされることへの言及

[ahwjdekf]

バイナリコンパイル言語に頼らざるを得ない立場が、あからさまに露呈したケースですね。

[kayws426]

Pythonでは解決したものの、ほかのエコシステムでは解決できていないのではありませんか？ だから事前ビルド済みのバイナリを提供するのでしょう。