プログラミング

geomean 4〜12%は出ていた——CPythonのJITが止まった理由は、性能ではない

「PythonのJITが削除される」という見出しだけが流通しています。ところがPEP 836の本文を開くと、性能の項目は埋まっている。3.15時点でpyperformanceのgeomean 4〜12%、1年目に設定された下限は5%でした。2日で2本のPEPが撤回された理由は別のところにあります。本番でPythonを回している側にとって、原因が性能ではないという事実は判断を変えます。

要点

• 撤回／JITをサポート対象へ昇格させる道筋を定めたPEP 836が2026年10月19日に撤回。翌20日、JITビルドのLLVM依存を外すPEP 774も撤回。2日で2本
• 性能／3.15時点の実測はpyperformanceのgeomeanで4〜12%。1年目のマイルストーンが定めた下限は5%
• 外れた要件／保守体制・ツーリング統合・配布。PEPは各段に複数の保守担当を置くことを中心的な目標に掲げていた
• 撤回の弁／「現行版を前に進める個人的な余力がないと感じている」（Savannah Ostrowski、2026年10月19日の討議スレッド57番目の投稿）
• 資金／PEPは「当初の主要な企業スポンサーが専従の資金提供を縮小した」と記す。現在はArm、FastAPI Labs、OpenAIからの継続的な企業貢献とボランティアの組み合わせ

一次ソースが4点に分散しているため、要約の過程で「性能が足りなかった」という誤読が生まれています。PEP本文の数字を並べると、結論は逆になります。

何が起きたか

JITは3.13で実験的機能として入り、以後PEPなしで main に置かれていました。2026年6月、Steering Councilが「正式な手続きを経ていない」としてJIT作業を停止させ、昇格の道筋をPEPで示すよう求めます。

その応答が、2026年7月2日作成のPEP 836「JIT Go Brrr: The Path to a Supported JIT Compiler for CPython」。著者はSavannah Ostrowski、Ken Jin、Brandt Bucherの3名、対象はPython 3.16です。

10月19日、討議スレッドの57番目の投稿で Ostrowski が撤回を告げます。同じ投稿で、Steering Councilがこの規模の提案に高い水準を課すのは正当だとしたうえで、現行版を前に進める個人的な余力がないと述べています。

同時に、技術的方向性——free-threaded対応とメソッド単位のフロントエンド——は今も正しいと考えており、リファレンス実装を公開して他者が引き継げるようにするとも書いています。

翌10月20日16時05分（UTC）、Ostrowski は「PEP 836の撤回を受けて」としてPEP 774も撤回しました。こちらは deferred 状態だったPEPです。

性能の項目は埋まっていた

PEP 836のアブストラクトはこう書いています。Python 3.15において、JITはインタプリタに対して測定可能で再現可能な高速化をもたらしている——測定されたTier 1プラットフォーム全体でgeomean 約4〜12%。

PEP付録の実測値です。

• jones（M3 Pro、macOS）／JIT+TAILCALL。1.126倍＝12.6%高速
• sulaco（AmpereOne、Linux aarch64）／JIT。1.073倍＝7.3%高速
• ripley（i5-8400、Linux x86_64）／JIT。1.069倍＝6.9%高速
• prometheus（Ryzen 5 3600X、Windows）／JIT+TAILCALL。1.047倍＝4.7%高速

そしてマイルストーンの1年目が定めた性能要件は、「JIT＋GIL が GIL インタプリタ単体に対して5%を下回らないこと」。既存の性能改善を大きく後退させない、という趣旨の下限です。

つまり1年目に課されたのは「伸ばせ」ではなく「落とすな」で、4プラットフォーム中3つがそれを上回っていました（Windowsの4.7%のみ下限をわずかに下回ります）。1年目の主眼は性能ではなく開発者体験の改善に置かれていた、とPEP自身が明記しています。

2年目（3.17の最初のベータまで）の要件は別です。free-threadingインタプリタ単体に対して、JIT＋free-threadingでgeomean 20%以上。これがJITをmainに残すための最低ラインとされていました。撤回により、この20%は未着手のまま残っています。

外れたのは保守体制だった

PEP 836の Maintenance Model は、JITをフロントエンド・オプティマイザ・コード生成バックエンドの3段で保守していると説明し、各段に複数の現役保守担当を維持し、どの部分も1人に依存しないことを中心的な目標に掲げていました。

3.15サイクルでは最適化作業を小さく実行可能な単位に分解し、トレース記録への移行に十数名を引き込み、定常的なオプティマイザ貢献者を増やした——と、達成したことも具体的に書かれています。

それでも足りなかった。撤回投稿の理由が「個人的な余力がない」である以上、組織として広げる努力はしていたが、PEPを推進する一人の負荷が下がらなかったという読み方になります。

資金面の記述も見ておく価値があります。PEPは「当初の主要な企業スポンサーが専従の資金提供を縮小した後もコミュニティ主導の取り組みとして継続してきた」と書き、現在はArm、FastAPI Labs、OpenAIからの継続的な企業貢献とボランティア作業の組み合わせだとしています。

ベンチマーク用マシンの一部も個人とArmの拠出です。言語処理系の中核が、専従資金のない状態で3段構えの保守を要求されていた——というのが、この撤回の構造です。

技術的に何が変わるのか

JITは今も入っています。3.15のWindows／macOS公式バイナリはJITをビルド済み・既定で無効の状態で同梱しており、PYTHON_JIT=1 で有効になります。どのリリースで実際にコードが削除されるかは、一次ソースで確認できていません。

捨てられたのはトレース記録からの移行計画です。PEP 836の1年目は、フロントエンドをトレース記録からメソッド単位へ差し替えることでした。スタック上にSSAに近い性質を持たせ、「region」として高水準の制御フロー構造を保つ設計で、ミドルエンドとCopy-and-Patchバックエンドはほぼ再利用する想定。Copy-and-Patchは分岐を既に扱えるため、追加で必要なのは制御フロー合流点での型情報のマージだけでした。

ランタイムが成熟するほどトレースの扱いやすさは失われる、というのが著者の主張です。

プロトタイプの数字は、現行より低い。

• メソッドJITのPoC／GILビルドのx86-64 Linuxで、pyperformanceとPystonのマクロベンチに対しJIT無効比5〜6%
• 同条件の現行トレースJIT／7〜8%（ただし3年かけて育てたもの。PoCは数か月）
• PoCの未対応／ジェネレータ／コルーチン、多態性。いずれも現行のトレース版は部分的に対応している
• 差分規模／テストを除き50ファイル、約4,300行追加・約7,400行削除

欠けた分はプロファイル情報、パス分割、コールドコード除去、再特殊化で取り戻す計画でした。

free-threadingは一級の目標でした。グローバル／ビルトイン参照やtype watcherに依存する最適化はfree-threadingで安全ではなく、素朴に直すとgeomeanで1〜2%の損。その先に、参照カウントとアトミック操作を外してGILビルドを上回りうるという主張がありました。2年目の20%という数字は、ここに賭けたものです。

なお、リファレンス実装はPEP本文からリンクされています。main に対する動作するPoCがopenai-oss-forks 側のブランチとして公開されているため、設計を追いたい場合はPEPの Reference Implementation 節から辿れます。

配布の筋も切れた

JITビルドはステンシル生成にLLVMを必要とします。当初はLLVM 16、近年はLLVM 19。これは開発者と再配布者の双方にセットアップ負担をかけ、OSが同梱するLLVMのバージョンがJITの要求と一致しない、という問題を生んでいました。

PEP 774は、生成済みステンシルをCPythonリポジトリに取り込んでこの依存を外す案でした。

• 対象／6プラットフォーム分のステンシルファイル。Tools/jit/stencils/ に置く
• サイズ／6プラットフォーム合計で7.2MB。直近90日のコミット比較ではステンシル1ファイルあたり0.03MB、6ファイルで上限0.18MBの増加
• 将来のリスク／レジスタアロケーションを変えると命令あたり5〜6種の変種が入り、5〜6倍に膨らみうる
• 結末／2026年10月20日に撤回

再配布者がLLVMの特定バージョンに縛られる状況は、当面動きません。自社でCPythonをビルドしている場合、この一点だけで影響が出ます。

なぜ日本でまだ正しく伝わっていないのか

報道の起点がLWNの購読者限定記事で、そこから英語圏のアグリゲータが「JITが削除される」という形に要約したためです。

実体を掴むには、一次ソース4点を突き合わせる必要があります。

1. PEP 836の性能表（3.15時点の実測）とマイルストーン（1年目5%／2年目20%）
2. PEP 774の撤回日と、ステンシルのサイズ
3. PEP 836の Maintenance Model（3段の保守体制と、スポンサーの縮小）
4. 討議スレッド57番目の撤回投稿（理由と、技術的方向性の維持）

並べると結論が変わります。性能で失敗した話ではなく、保守担当の人数とツーリング・配布の要件が埋まらなかった話。2026年10月29日時点で日本語の解説は確認できず、英語側でもPEPの数字まで降りた記事は見当たりません。

エンジニアにとって何が変わるか

3つに分けて書きます。

①設計

CPythonの素のインタプリタ速度に賭けた計画は引き直しになります。ホットパスは従来どおり外側で取る——Cython、mypyc、Numba、PyTorch Compile、MetaのCinderX。PEP 836自身が、JITをこれらの代替ではなく「backstop」（どこにも拾われずに実行されるコードの受け皿）と位置づけていました。

free-threadingの採用判断も分けて考える必要があります。JIT併用で伸びるという前提は2年目のマイルストーンに置かれたもので、現時点では根拠がありません。free-threading単体の損得で判断してください。

②調達・運用

性能前提の容量見積もりは、バージョンではなくビルド構成で見ることになります。

• PYTHON_JIT／既定値。3.15のWindows／macOS公式バイナリはビルド済み・無効
• free-threading／有無
• LLVM／再配布者が使っているバージョン
• メモリ／PEP 744によれば、JITは実行機械語の領域を追加で確保するためインタプリタより10〜20%多くメモリを使う。ベンチマークはコードとデータの比率が高くオーバーヘッドが目立ちやすい点も同PEPが注記している

③キャリア

落ちたのは実装力ではなく保守体制でした。Copy-and-Patchのバックエンド、型特殊化のミドルエンド、トレードオフを握るフロントエンド。この3層を継続的に保守できる人材はCPythonに限らず不足しています。

PEPが資金提供元としてArm、FastAPI Labs、OpenAIを挙げていたことは、この職能に金が付いている傍証です。同時に「主要スポンサーが専従資金を縮小した」とも書かれている。需要はあるが、専従ポジションとして安定していない——というのが処理系エンジニアの現在地です。

確認できなかった点

• 削除のPR／期日／JITのコードを main から削除する具体的なPR・issueと期日。LWNの見出しは未来形だが、記事本体は購読者限定で取得できず、GitHub上の該当PRも確認できなかった
• Steering Councilの原文／反対理由の原文。保守体制、互換性、評価計画、ツーリング統合、「期待する性能が楽観的すぎる」はいずれもLWNを二次メディアが引いた記述に拠る
• issue #139038の内容／3.16の must have として「各段に2名以上の保守担当」が挙げられたとする記述は、本記事では確認できなかった。本文の「各段に複数の保守担当」はPEP 836本体のMaintenance Model の記述による
• PEP 744のステータス／本記事の参照時点でもDraftのまま

出典

• 一次／PEP 836「JIT Go Brrr: The Path to a Supported JIT Compiler for CPython」（2026年7月2日作成、Status: Withdrawn、Python-Version: 3.16、Resolution: 2026年10月19日）／性能表、マイルストーン、Maintenance Model、メソッドJITのPoC、差分規模、リファレンス実装
• 一次／discuss.python.org, PEP 836討議スレッド 57番目の投稿（Savannah Ostrowski、2026年10月19日）／撤回とその理由
• 一次／PEP 774「Removing the LLVM requirement for JIT builds」（Status: Withdrawn）および同討議スレッド 42番目の投稿（2026年10月20日 16:05 UTC）／ステンシル6プラットフォーム7.2MB、5〜6倍のリスク
• 一次／PEP 744「JIT Compilation」（Status: Draft）／JITのメモリ増加10〜20%
• 二次／LWN.net「Python's experimental JIT to be removed」（報道の起点、購読者限定のため本文は未取得）
• 二次／InfoWorld「Python jettisons the native JIT, at least for now」／LWNを引いた経緯の整理
• 二次／The Register（2026年6月8日）／Steering Councilによる作業停止の経緯
• 参考／CinderX（Metaの実験的JIT）

本記事は2026年10月29日時点で公開されている情報に基づいています。数値はPEP 836・774・744の本文、および discuss.python.org の該当投稿で確認しました。LWNの記事本体は購読者限定のため未取得で、Steering Councilの反対理由は二次ソース経由の記述です。JIT削除の具体的な時期は決まっていません。