Python 3.12向けWindows版SciPyビルド、小さな奇跡と評価
(labs.quansight.org)- conda-forgeのWindows版SciPyビルドがPython 3.12.0のリリースから2日後に提供され、SciPy系のPython 3.12移行は数カ月の停滞ではなく、数日の遅れで進んだ
- Python 3.12でdistutilsが標準ライブラリから削除されたため、SciPyは
numpy.distutilsの代わりにMesonビルドツールへ移行することを決めた - Mesonはconda-forgeが使っていたMSVC+gfortranの組み合わせを拒否する予定であり、Windowsにはconda-forgeが利用できる無料のABI互換Fortranコンパイラがなかった
- conda-forgeは、WindowsでSciPyを再ビルドできない場合、SciPyに依存する少なくとも約1,000個のパッケージの移行が全プラットフォームで遅れるか、Python移行からWindowsを除外せざるを得ない状況を想定していた
- LLVM 17.0はFlangで
-flang-experimental-execフラグを削除した最初のリリースであり、Flangは「0.8 level maturity」程度の成熟度と見積もられていた - Mesonにllvm-flangの処理を追加した後、SciPyのビルドとインストールに成功し、テストは
54,987 passed、2,866 skipped、245 xfailed、11 xpassed、1 warningで100%通過した {p:100}
3件のコメント
Hacker Newsの意見
本当に素晴らしい記事だったし、これで Python 3.12 で
pip installが失敗していた理由も分かったが、今後はもっと明るく見える。Python は好きだが、Python パッケージングがなぜどうにか管理可能なレベルの混沌なのかを理解する助けにもなった。
原因は Python 自体ではなく、C/C++/Fortran のビルドツールが標準化されていないことと、エコシステムの巨大さにあり、ある程度は避けられない複雑さでもある。
これが動いていること自体、奇跡に近い。
Python の成功は、主要な 混成言語パッケージ を利用できたことによる面が大きく、ほかの主流言語のパッケージマネージャはこうした問題をほとんど扱っていない。
たとえば Rust の
cargoは素晴らしいが、大半は Rust 専用コードのパッケージングを前提にできるし、コンパイル言語でありながら言語がコンパイラを「所有」しているので、ソースビルド配布戦略が成り立つ。cargoが Fortran を標準でどう扱うのかは知らないが、Windows で上位のcargoパッケージが Fortran コードを必要とするなら、うまく回るとは思えない。Python エコシステム最大の改善は、バイナリパッケージ形式である wheel の標準化であり、その時点でようやく科学技術系 Python エコシステムが Windows で本格的に栄え始めた。
ただしバイナリ互換性は、とくに言語や CPU をまたぐときには途方もない悩みの種になる。
ソフトウェアエコシステムの複雑さは指数関数的に増しているように見えるが、最終的に バベルの塔のような崩壊 に向かわないよう防いでいるものは何なのか気になる。
もちろんソフトウェアだけの問題ではないが、良い例ではある。
人々が自分の好きなパッケージマネージャを Python のものと比較して Python はひどいと結論づけるのをよく見るが、実際にはそうではない。
ただ、よく分からないのは、なぜ Python 側の人たちが Fortran の代わりに C/C++ 数学ライブラリ を使わないのかということだ。
混沌の上にさらに混沌が積み重なっているわけだ。
Linux が、緩く連携したハッカーたちによって、時には非実用的なイデオロギー的制約を抱えながら運営される軋む辺境の事例だったころ、優秀な人たちがそこに対応を付けようとして膨大な努力を注いだのは素晴らしいことだった。
だが今や、その軋む辺境の事例は、制約の性質がほとんど敵意に近い 独占的システム であり、サイバー小作人のような者たちによって運営される場になってしまったので、それを支援しようとする作業を以前ほど前向きには見られない。
一方で、こうしたツールを誰もが使えるようにしようという深い配慮は本当に素晴らしく、その作業には拍手を送りたい。
方向を変えろと言いたいわけではまったくなく、ただ考えさせられる。
以前なら「わあ、この作業が進んで本当によかった」と思っていたが、今では「わあ、あの優秀な人たちがこんなことに縛られなくて済んでいたら、何を成し遂げられただろう」と思うことのほうが多い。
何度も出ているように、SciPy 開発者たち はボランティアだ。
話の大半は、SciPy が Windows 向けのオープンソース Fortran コンパイラを誰かが作ってくれることに期待するしかなかった理由を説明しており、救いは主に NVIDIA の開発者たち がもたらしたように見える。
SciPy は、Python コア開発者たちが Windows 上の Python 用ツールチェーンとして MinGW ではなく MSVC を選んだ、愚かで非常に偏った決定の代償を払っている。
その動機は Microsoft の支援に由来すると見ている。
コア開発者の一覧には Microsoft 社員がかなりいて、彼らはその一覧に参加する対価を Microsoft から受け取っており、しかも Microsoft は CPython プロジェクトの CI サーバー費用まで負担している。
Python がツールチェーンに独占的ツールを使っていなければ、この問題全体は回避できていた。
「Meson が conda-forge で使われていた MSVC+gfortran の組み合わせを拒否しようとした」というのは、バグのように聞こえる
ビルドツールの目的は指示されたコマンドを実行することであって、「ごめんね Dave」と言って止めることではないと思う
問題は、MSVC と gfortran が使う C ランタイム、特に gfortran 自身のランタイムライブラリが C で書かれているにもかかわらず、両者の ABI に互換性がないこと
NumPy が使っていた回避策は、Fortran オブジェクトを DLL にリンクして import library という間接層を追加し、MSVC をなだめるやり方だった
そのため、この種の DLL を作るための追加作業が必要だった
それはビルド記述ファイルでやるにせよ Meson でやるにせよ必要で、SciPy 側はどちらにもこの間接層を実装したがらず、Meson 開発者も積極的に手伝いたがらなかった
もちろん Meson 開発者は Fortran や Cython のサポートのような一般的な支援はしていたが、危うい足場を提供したくはなかったのだろう
実際、これはハックにかなり近く、たとえば Fortran 側が Python/C 側で開いたファイルを使わなかったからこそ動いていた
https://web.archive.org/web/20180711144501/https://pav.iki.f...
個人的には Meson より Bazelのほうをよく見かける
Meson は Python で書かれているので SciPy には良い選択に見えたのだろうし、最終的にうまくいったのだから祝うべきことだ
それでも、いろいろな奇妙さや複雑さや問題があるにもかかわらず、CMakeが依然として標準に最も近いと思う
MSVC/gcc/clang をサポートできるようにコマンド自体を合成することもある
未知の組み合わせについてコマンドを合成してくれと言われれば、当然「ごめんね Dave」と言うしかない
近く公開する Meson 競合ビルドシステムの作者であることは明かしておく
ただ、今の考えに気づかせてくれた、あまり知られていない小さな宝石のような rant が [1] だ
要するにビルドシステムは、ユーザーが実行しろと言ったコマンドを実行すべきで、それで終わり
ときにはプログラマーが本当に自分のやっていることを分かっているからだ
恥ずかしい話だが、そのコメントを読む前は自分のビルドシステムを魔法のようなものにしようとしていた
だがそのコメントを読んでから、人々がビルドシステムを嫌う理由はまさにその「魔法」なのだと気づいた
[1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273
こういうことはみんな WSL2を使って終わりだと思っていた
わざわざネイティブ Windows 版をビルドしようとする理由は何だろう？
仮想マシンで作業するのは不便だし、統合性も落ちる
学生もそうだ
とくにその上で Docker Desktop を使えるときはなおさらだ
理想的ではない状況から最善を引き出していると言える
καταστροφήのκαταは「突然さ」ではなく、「下へ」あるいは「〜に従って」に近く、悪い方向へ曲がるという含意が強いκαταの反対は普通αναだが、αναστροφήは文字どおりには「上向きに回ること」または反転を意味するだから「良い転換」という意味の
ευστροφη、つまり eustrophe のほうがよりよい造語かもしれないそれでも JRR Tolkien と語形成をめぐって議論して勝てるなら、それは
ευκαταστροφη、つまり幸運だろう全体として、あふれる恩寵を捉えている点がよく、そういうものが世界に喜びと幸福を与える
katastrofiのkataは実際には「against」に近いので、katastrofi は物事が「背を向ける」ことに当たる最高の BLASはたいてい C で書かれているという印象がある
MKL、BLIS、OpenBLAS のようなものだ
C と Python だけでどこまで行けたのか気になる
今始めるなら単に
libflameを選んでいたのかも気になるもちろん SciPy には反復法や疎行列などほかにも多くの機能があるので、Fortran を避けるのは難しいかもしれない
それでも Fortran はすばらしい言語だし、Windows でのツール事情が少なくとも改善し始めているのは喜ばしい
SciPy 自体にも Fortran コードが多く含まれており、書き直すには年単位の人的リソースが必要になる
実現可能になってからは、Fortran を使っていた中核部分のいくつかが実際に削除された
たとえば FFT 関連の部分だ
すばらしい記事だ
今年は Python バインディングを持つ CMake C++ プロジェクトのモダナイズに多くの時間を費やし、新しい feedstock として conda-forgeへの追加にも成功したので、自信を持って言える
もし私が神聖皇帝になったら、IT 関連の最初の施策として、あらゆる宇宙から永遠に Windows を根絶するだろう
とても素朴な質問ですが、Fortranのセマンティクスはそれほど違うのでしょうか。まずCに変換して、その後Cコンパイラでコンパイルすることはできないのでしょうか?
その後はCとして保守することもできるのでは?
こうした古いライブラリを保守するFortranの人はそれほど多くない気もしますが、それでも保守は必要なのではありませんか?
Fortranにはポインタがなく配列しかなく、関数引数がエイリアスを持てないため、ひとまず
COMMONブロックの恐怖は脇に置くとしても、積極的な最適化やベクトル化がしやすいです標準的なFortran数学ライブラリは、単純によく動いて高速です
C/C++でも、特にCの
restrictキーワードを使えば、同等の速度のコードを書くことはできますただし既存コードを
f2cの段階で変換すると、多くの場合で性能が大きく低下しますFortran開発者も十分にいます
アプリケーション開発にはひどいですが、それはFortranの主戦場ではありません
f2cは数十年前から存在しています
ちょっとした疑問があるのですが、私の理解では
aarch64とarm64は同じものです私の認識違いでしょうか?
[1] https://www.phoronix.com/news/MTY5ODk
aarch64は通常Linuxを指し、arm64は通常macOS ARMを指しますなぜ名前が違うのかを理解できるほど、この分野に詳しいわけではありません
Pythonのビルドシステムの変化は本当に追いかけにくいです
Windowsでの性能値も気になります
ただ、第一義的には重要ではないかもしれません
本格的な作業はおそらくLinuxマシンで動くでしょうから
大きな移行は、みんなにPEP 517を受け入れてもらうこと、特に既存のSetuptoolsプロジェクトを移行することでした
時間の99.9%はOSではなくユーザーコードが実行されるためです
バイナリコンパイル言語に頼らざるを得ない立場が、あからさまに露呈したケースですね。
Pythonでは解決したものの、ほかのエコシステムでは解決できていないのではありませんか？ だから事前ビルド済みのバイナリを提供するのでしょう。