この記事は後半です。前半は Qiita にあります: CPythonの実験的JITはなぜ止まったのか：4〜12%改善でも消える理由を読む
画像: www.theregister.com より
画像: arxiv.org より
前半で見た通り、CPython の実験的 JIT は 3.15 で pyperformance の geometric mean をおよそ 4〜12% 改善した。x86-64 Linux でも、macOS AArch64 でも数字は出ている。それでも Steering Council は、JIT を main に置いたままにするかどうかを、速度ではなく別の軸で見直した。
その別の軸が、保守と互換性だ。Python の実行系は、ただコードが動けばよいわけではない。デバッガ、プロファイラ、拡張モジュール、配布物、再現性のあるビルド。そうした周辺まで含めて、CPython は一つの基盤として扱われている。JIT が内部構造を変えると、同じコードでも観測のされ方が変わる。速いか遅いかより先に、「何が保証されるのか」が問われる。
PEP 744 はその点を最初から曖昧にしていたわけではない。むしろ、JIT は non-experimental になるまでは production で使うべきではなく、壊れたり削除されたりしてもおかしくないと明記していた。つまり、実験であること自体は合意済みだった。問題は、実験が長引くうちに、その曖昧さをいつまで許すかが争点になったことだ。
Steering Council が PEP 836 に求めたのは、「JIT を supported feature にする条件」ではなく、「main で実験を続けてよいか」を判断できる材料だった。ここが重要だ。supported にするかどうかの前に、そもそも実験を main に置き続けることが妥当かを詰めていた。
懸念はかなり具体的だった。メモリ使用量、プラットフォームごとの差、セキュリティ、第三者ツールとの整合、redistributor への影響。特に厄介なのは、JIT を有効にしたときのユーザー向けの見え方だ。Python では、実装の癖に依存したコードが少なくない。だから、内部最適化の変更が「見えてはいけない差分」を生むと、その差分は性能向上ではなく互換性問題として扱われる。
PEP 836 は、そのあたりをかなり前向きに整理しようとしていた。初年度は method-based frontend に移行し、free-threading に対応し、デバッガやプロファイラの対応も広げる。これは単に新しい構造を採るという話ではない。むしろ、JIT の挙動を理解しやすくし、壊れたときの切り分けをしやすくするための設計変更だった。
ただ、Council 側はそこにまだ足りないものがあると見た。とりわけ、性能基準の具体性が足りない点と、互換性確認の時期が遅いという点だ。PEP 836 では、上位 PyPI パッケージのテストを回す互換性レビューが 3.17 の release candidate 期に置かれていたが、Council はそれを遅すぎると考えた。不具合を見つけるのが 2028 年近くまで後ろ倒しでは、実験のコストが見えにくくなる。
ここで数字の扱いも少しややこしい。PEP 744 では、non-experimental になる条件として「少なくとも 1 つの人気プラットフォームで意味のある改善」、だいたい 5% 前後を挙げていた。一方 PEP 836 では、JIT + free-threaded build で pyperformance の geometric mean を 20% 改善することを、3.17 の first beta までの最低目標に据えている。
この差は単なる上方修正ではない。比較対象が変わっているからだ。JIT 単体の話から、free-threading と組み合わせた話へ移っている。つまり、JIT は「速くなったら終わり」ではなく、CPython の次の大きな変更と一緒に成立するかを見られる段階に入っていた。ここで求められるのは、ベンチマークの上振れではなく、将来の本命構成に耐えるかどうかだ。
だから、PEP 836 の withdrawal は敗北宣言というより、条件設定の難しさが露出した結果に近い。速度の実績はある。けれど、その速度を main に置き続けるための説明責任が重い。しかもそれは、単独の最適化技術としてではなく、配布、保守、セキュリティ、ツール互換まで含めた責任だ。
この JIT を使うなら、私は本番の「標準機能」としてではなく、まずは検証環境で性能と観測性を確認する。とくに見るのは、速くなるかではなく、デバッグやプロファイリングが壊れないか、配布手順が増えないか、既存の依存関係に変な揺れが出ないかだ。速度改善が 4〜12% でも、運用で 1 つ手順が増えると帳消しになる現場は多い。
逆に言えば、JIT が本当に広く使われるためには、性能の伸びより先に、説明できることを増やす必要がある。どの条件なら有効化してよいのか。何を保証し、何を保証しないのか。どの時点で互換性レビューを始めるのか。PEP 836 が最後まで詰めようとしたのは、その線引きだった。
だから「速くなったのに消される」というより、「速くなったからこそ、曖昧さが許されなくなった」と読むほうが近い。JIT の価値は否定されていない。ただ、CPython の main に残るには、性能以外の宿題がまだ多かった。
