Pythonの実験的なJITが削除される
Python's experimental JIT to be removed (lwn.net)
要約
Python 3.13で導入された実験的なJITコンパイラが、CPythonのメインブランチから削除される見込みです。Pythonステアリングカウンシルは、メンテナンス、互換性、成功指標、タイムラインに関する懸念に対処するPEPが承認されない限り、JITプロジェクトの中断を発表しました。JITメンテナーはPEP 836を撤回し、プロジェクトは現時点では終了しました。
全文翻訳
Pythonの実験的なJITが削除される
[LWN購読者限定コンテンツ]
LWN.netへようこそ
以下の購読者限定コンテンツは、LWNの購読者によって提供されました。何千人もの購読者が、Linuxおよびフリーソフトウェアコミュニティからの最高のニュースのためにLWNに依存しています。この記事を楽しんだら、LWNを購読することを検討してください。LWN.netへの訪問に感謝します！
Pythonの実験的なジャストインタイム（JIT）コンパイラは、2024年にCPythonの3.13リリースに追加されましたが、廃止されることになりました。6月、Pythonステアリングカウンシルは、メンテナンス、互換性、明確な成功指標、および完了までのタイムラインに対処するPython Enhancement Proposal（PEP）が承認されるまで、CPythonのメインブランチでのJIT作業を一時停止すると発表しました。カウンシルの要求を満たすためにPEP 836（「JIT Go Brrr: CPythonのためのサポートされるJITコンパイラへの道」）を作成した後、数ヶ月にわたる議論を経て、JITメンテナーはPEPを撤回しました。今のところ、かつて有望だったプロジェクトの開発は終焉を迎えたようです。
JITは、2024年初頭にBrandt BucherによってCPythonに追加されました。一般的に、このような主要な機能は、カウンシルが標準トラックPEPを承認した後にのみ導入されると予想されます。BucherはPythonコア開発者スプリントでJITに関する講演（YouTube動画、スライド）を行い、機能をマージする意向を発表しましたが、承認のためにPEPを作成または提出する段階には至っていませんでした。彼は、Python 3.13のリリースマネージャーも務めていたステアリングカウンシルメンバーのThomas Woutersによって、PEPの作成を促されました。
BucherとSavannah OstrowskiはPEP 744（「JITコンパイル」）を起草しました。これは情報PEPであり、Pythonコミュニティに情報を提供するだけで、機能またはプロジェクトを進めるための正式なコンセンサスを表すものではありません。LWNは2024年4月にPEP 744の議論を取り上げ、その後、PyCon US 2024でのBucherのJITに関する講演、およびPyCon US 2025でのフォローアップ講演を取り上げました。
PEP化する
JITの作業は、今年6月にカウンシルがJITメンテナーに対し、標準トラックPEPを作成するよう正式に要請するまで、PEP 744に基づいて進められていました。なぜカウンシルが新しいPEPを要求する時期だと判断したのか、Antoine Pitrouが疑問に思ったかもしれません。Woutersは、この要求には「単一の引き金となるイベントはなかった」と述べましたが、カウンシルはしばらくの間このトピックを議論しており、JIT作業が他のプロジェクトに干渉しないようにすることを望んでいました。「JITをインストルメンテーション、デバッグ、プロファイリングと連携させるための作業が行われていました。また、外部JIT（CinderXなど）、JITに隣接するもの（NumbaやPyTorchのコンパイルなど）、そしてティア3 JITに関する議論もありました。」カウンシルは、Python 3.15ベータリリース後まで待って、「3.15の現状で問題ないことを明確にする」ことを望んでいました。
カウンシルは、JITを「CPythonのサポートされる、実験的でない部分として」主張するPEPを求めました。その保証、メンテナンスコミットメント、および再配布者への影響などが含まれるべきでした。カウンシルはPEPの提出と承認のために6ヶ月の締め切りを設定しました。それが失敗した場合、カウンシルはJITコードをCPythonメインブランチから削除することを要求しました。
Bucher、Ostrowski、Ken JinはPEP 836を起草し、7月3日にPythonフォーラムでコミュニティからのフィードバックのために公開しました。多くの議論が巻き起こり、好意的な意見も批判的な意見もありました。コメントの主要なテーマの1つは、WoutersやMark Shannonによるコメントで、ドラフトが2つの別々のPEPであるべきだと感じさせたことでした。例えばShannonは、PEPはJIT作業を受け入れるための目標のみをカバーすべきであり、実装の詳細は含めるべきではないと考えました。追加情報への呼びかけもかなりありました。
Bucherは、2つのPEPにすべきだという提案に少し反発し、OstrowskiはPEPの構造を擁護しました。「PEPにあるような目標を、計画とそれに伴って考えてきたすべてを共有できずに概説することは、私にとって不快です。私にとって、計画のない目標は本当の目標ではありません。」
9月にこのトピックを最後に確認したとき、新しいPEPの開発コミットメントやカウンシルからの正式な声明がないまま、PEPに関する議論はスローダウンしていました。当時のカウンシルからの最後の言葉は、8月6日の会議の要約の形で、PEPの著者と会談し、「PEPの状態と、カウンシルがPEPを要求した際に尋ねた質問に答えていたかどうかを議論していた」というものでした。
メインブランチでの実験
9月21日、Woutersは、Ostrowski（彼女はPEPの共著者であるため参加しなかった）を除くステアリングカウンシルの声明を投稿しました。声明は、PEPはカウンシルの要求で強調されたすべての質問に答えていたが、「おそらく、他の質問よりも説得力に欠けるものもあった」と述べています。
カウンシルは、JITがサポートされる機能であるための基準や、それをサポートされると見なすべきかどうかを求めていたわけではないことを明確にしたいと考えていました。むしろ、カウンシルはJITがCPythonのメインブランチでの実験として継続されるべきかどうかを評価していました。
メインブランチでの実験を許可することの問題点の一部は、統一された設計の欠如であり、コア開発者、パッケージメンテナー、ユーザーが実験によって動作やAPIサーフェスが変化する際に直面する不確実性です。
カウンシルは、PEPはサポート計画、パフォーマンス基準について十分に具体的ではなく、他の多くの領域については曖昧すぎるか楽観的すぎると述べました。声明には、カウンシルが「PEPで明確にされるか、少なくとも議論され却下される」ことを望んでいた10項目のリストが含まれていました。カウンシルのリストは、メモリへの影響からセキュリティまで、懸念事項を網羅していました。例えば、プラットフォームの互換性については、カウンシルはJITが新しいプラットフォームに容易に採用できるように設計されていることを確認したいと考えていました。JITの設計が特定のプラットフォームに依存せず、メンテナンスのためにプラットフォーム固有の知識を必要としないという保証を求めていました。
カウンシルが指摘したもう一つの領域は、ユーザーへの影響でした。PEPは、JITが有効になった場合のユーザーから見える違いについて「過度に楽観的」であると述べました。インタープリタの設計の特殊性に依存するユーザーケースは多く、「他のPython実装や、メジャーなPythonバージョン間でも見られたように」存在し、それらの違いがどのように扱われるかについての明確化を求めていました。それらはバグと見なされるのか、動作の違いが避けられない場合にどのように状況が処理されるのか、などです。
カウンシルによると、セキュリティは「PEPで十分に扱われていない領域」であり、Pythonセキュリティ対応チームとの議論が適切であり、セキュリティレビューもサポートステータスの基準の一部であるべきだと示唆しました。
PEP 836は、Python 3.17の最初のリリース候補（2028年8月頃に予想される）に対応する互換性レビューのマイルストーンを指定しており、トップPyPIパッケージのテストスイートを実行してJITがそれらを壊したかどうかを確認することを含んでいました。カウンシルは、そのタイムラインを大幅に前倒しすることを望んでいました。「それはあまりにも遅すぎると考えており、互換性レビューは可能な限り早く開始される、継続的かつ進行中のプロセスであるべきです。」
カウンシルはまた、JITの設計上の決定が「CPythonの開発、メンテナンス、サポートに最終的に責任を負う開発者のより大きなグループによる重要なレビューなしに行われる」ことを懸念していました。結論として、PEP 836は「我々が尋ねた質問にほとんど答えている」が、カウンシルは「このPEPについて発言を求められる前に、コミュニティのサポートとコンセンサスを測る」ために、これらのトピックについてさらなる議論を求めていました。
Jinは数日後に返信し、カウンシルの詳細なフィードバックに感謝し、グループがその提案に取り組むと述べました。
撤回
検討の結果、PEPの著者はカウンシルの承認を追求しないことを決定したようです。10月19日、Ostrowski（彼女はPython 3.16および3.17のリリースマネージャーでもある）は、PEPが撤回されることを発表しました：
ステアリングカウンシルは、この規模の提案に対して当然ながら高い基準を設定しており、現在のバージョンを前進させる個人的な帯域幅がないと感じています。私たちは、PEPで概説された技術的な方向性、フリースレッドサポートやメソッドベースのフロントエンドを含め、CPythonにおけるJITの可能性について引き続き楽観的です。参照実装を公開し、撤回されたPEPからリンクしますので、興味のある方はそれを探求し、構築することができます。
Barry Scottは、それがJITの作業が停止したことを意味するかどうかを尋ねました。Brett Cannonは、メインリポジトリでの作業は停止するが、コミュニティが他の場所で作業を継続するかどうかはコミュニティ次第だと返信しました。Dunc Grahamは、カウンシルの締め切り前に代替PEPを提出する時間があるかもしれないと提案しました。Cannonは、JITを積極的に推進していた人々がそのPEPの著者または貢献者であったため、それは可能性が低いと述べました。
PEPが撤回されたため、JITはCPythonのメインブランチから比較的早く削除される可能性が高く、その削除によって引き起こされる可能性のある問題がPython 3.16開発サイクルの早い段階で対処されることが保証されます。JIT作業の元の推進者が引き続き作業を行う意図があるのか、それとも十分なコミュニティの関心があれば他の人が引き継ぐのを待つだけなのかは不明です。PEPの著者に確認を求めてメールを送りましたが、まだ返信はありません。