JITプロジェクトに関するSteering Councilの発表
(discuss.python.org)- CPythonの実験的なJITコンパイラは main ブランチで数年にわたって開発され、最近では実際の性能改善を示したが、サポートされる機能として残すには正式な PEP レビューが必要な段階にある
- PEP 744 は初期設計と恒久的な機能への移行基準を扱ったが、長期的なメンテナ、セキュリティレビュー、デバッグおよび外部プロセスツールのサポート、ランタイム保証、再配布者・ダウンストリームパッケージャーの義務については、まだ合意に至っていない
- Python Steering Council は、JIT を CPython のサポートされる非実験的機能にするための Standards Track PEP の作成を正式に要請し、PEP が受理されるまでは新機能・最適化・性能改善作業を main に反映することの停止を求めた
- 新しい PEP では、長期保守、既存の CPython 機能・ツールとの互換性、測定可能な成功指標とスケジュール、CinderX・Numba・PyTorch のようなサードパーティ JIT との関係、現在のアーキテクチャの安定性を扱う必要がある
- 6か月以内に PEP が提出・解決されない、または受理されなければ、JIT コードを main ブランチから削除し、main Python リポジトリの外で開発を継続しなければならない
背景と正式な要請
- CPython の実験的な Just-In-Time コンパイラは、この数年間にわたり複数の core developer とコントリビューターが main ブランチで開発してきた取り組みであり、最近の性能改善は現実的で励みになる結果である
- この措置は JIT の作業や参加者への批判ではなく、プロジェクトが長期間にわたり進行し、複数回の再設計を経てきたため、CPython プロジェクト内での JIT の非公式な位置づけを再評価すべき時期に来たという判断である
- JIT は最初に main にマージされた際、実験として導入され、関連する PEP である PEP 744 は Informational PEP である
- PEP 744 は初期設計を扱い、JIT が恒久的な機能になり得る基準を概説したが、長期的なメンテナ、セキュリティレビュー、デバッグや外部プロセスツールのサポート、ランタイム保証、再配布者とダウンストリームパッケージャーの義務といった問いは未解決のままである
- Python Steering Council は、この程度の複雑さと規模を持つ変更には、より厳格な手続きが必要だったとし、これらの未解決の問いはコミュニティが PEP プロセスを通じて検討し、合意すべき約束だと判断している
- JIT を CPython のサポートされる非実験機能にするには、保証、保守の約束、再配布者への影響まで扱う Standards Track PEP が必要であり、コミュニティでの議論の後に Steering Council による正式な受理または却下の手続きが必要となる
- その PEP が受理されるまでは、main ブランチに新たな JIT 開発を反映すべきではなく、新機能、最適化、性能改善作業が停止対象となる
- バグ修正とセキュリティ修正は引き続き可能であり、停止要請の範囲は PEP 受理前の追加 JIT 機能の反映に限定される
PEP が扱うべき論点と6か月のスケジュール
- 競合提案を求める意図ではないが、今は代替提案について議論する良い時期でもあり、CPython main ブランチで PEP なしに実験を進めるべきではないという従来の見解とも一致している
- 単一の JIT 実装を1つ提案するよりも、複数の実装戦略を支援できる JIT インフラを説明する PEP のほうが適切かもしれない
- 有望な JIT tracing アプローチが引き続き複数提案されているため、インフラは単一戦略に強く結び付くのではなく、CPython 内でそのようなアプローチを容易に実験・評価できるようにすべきである
- PEP は、この規模と複雑さを持つサブシステムを長期的にどのように継続・保守するのか、また JIT に直接貢献しないメンテナやコントリビューターにどのような影響があるのかについて、明確な計画を示さなければならない
- PEP は既存の CPython 機能やツールとの互換性を扱う必要があり、free-threading、profiler、debugger などの機能と JIT の相互作用および保証を広く詳細に扱わなければならない
- PEP は明確で測定可能な成功指標とスケジュールを含む必要があり、性能目標、プラットフォーム対応範囲、メモリオーバーヘッドといった目標と時期を扱わなければならない
- PEP は他の JIT コンパイラとの関係を扱う必要があり、他の取り組みが基盤として利用できる一般的なインフラを提供する設計なのか、CinderX、Numba、PyTorch などのサードパーティ JIT との互換または非互換を想定しているのかを明らかにしなければならない
- PEP は、現在の JIT アーキテクチャが安定していると見なしているのか、それとも今後さらに変更される可能性が高いのかを扱わなければならない
- この一覧は完全なものではなく、コミュニティでの議論が進むにつれて追加の論点が加わる可能性がある
- PEP の提出と解決には 6 か月の期間が設定されており、この期間内に当該 PEP が受理されなければ、JIT コードは main ブランチから削除され、main Python リポジトリの外で開発を継続しなければならない
- この要請はプロジェクトの終了ではなく、CPython ランタイムへの大きな変更に必要な明確性と、コミュニティによる明示的なコミットメントを与えるための手続きである
1件のコメント
Lobste.rsの意見
それほど険悪には見えないが、少しぎこちないのは確か。JITがまだ実験的機能なら、マージが続いていること自体は問題ないように思える
Shannonのような人たちが「PEPは持ってくるが、ぎこちない衝突は避けられるようにしてほしい」と言うのであれば、これ以上進めないよう強いロックをかけなくてもよい程度には信頼できると感じる。この公開発表が非公開の会話の後に出たものかもしれないが、不必要な傷を残さずうまく進んでほしい
異なるJIT実装を許容するインターフェース提案は、高性能JITに何が必要かを大きく誤解しているように見える。JITの担当者たちにはいろいろ問題があったのだろうが、大きな問題の一つは、コアランタイムのデータ構造を大きく変えられなかった、あるいは変えようとしなかった点にあるように見える
もちろんPythonには、実装全体を事実上APIのように露出させてしまっている問題もある。それでも誰かがまずいことをしたら、型を書き直させることはできるはずだが、そのためには性能を本当に重視するコミュニティが必要になる。Pythonは歴史的に、性能が必要なライブラリはPythonで書かないという形でやってきたため、それが優先順位にも影響してきた。昔、言語性能の比較で、基本アルゴリズムの実装と、実際にはCライブラリのよく磨かれた高性能実装を包んだPython実装とが比べられていたのを覚えている
JITインターフェースの提案はRubyに着想を得たもののようで、Rubyではかなりうまく機能している印象がある。だからRubyに超高性能JITがないのかもしれないが、その程度でも十分かもしれない。PythonのJITがRubyのJIT程度に動くだけでも、多くの人は満足しそうだ
「異なるJIT実装を許容するインターフェース提案は、高性能JITに必要なものを大きく誤解している」というのが、なぜそうなのかよく分からない
言うとおり、Pythonが実装をAPIのように露出している状況はあるが、同じ理由でJITもそのAPI群を呼び出している。実際、一部の関数はJITが必要としたため、リンカに公開シンボルとして露出されたこともあった。個人的には、トレースJITではなくメソッドJITに取り組んでいて、プラグイン型JITのアイデアを以前から公に支持してきた
なぜこれをコアJIT開発者たちへの非公開の依頼として送らず、公開発表として出したのか気になる
どこかの人類学者が、オープンソースソフトウェアプロジェクトの官僚制について本を書くべきだと思うし、PythonとDebianは中心的な研究対象になるべきだ
非難ではない。こうした官僚制は結局のところ、分散した意思決定と合意形成のプロセスであり、この規模でうまく機能させるのは難しい
正直、Python 3につながった症候群と同じだが逆方向の効果が出たように見える。CPythonは主に実装者たちの楽しみのために存在していて、この変更は現在のやり方でハックすることに慣れた人たちにかなり大きな不便を与えそうだ
おそらく正しい方向は、JIT版を別実装として支援し、変更を許容しつつ、元のCPythonとの互換性はベストエフォートで追求させることだろう
「CPythonは主に実装者たちの楽しみのために存在する」という部分についても、SCやコア開発者との限られたやり取りから受けた印象では、むしろ逆だった。全体として、既存コミュニティを支え続けながら前進するというバランスを合理的に取ることに、かなり深くコミットしているように見えた