ハクソク

世界を動かす技術を、日本語で。

Python 3.15のJITが再び軌道に乗りました

2026年3月18日原文(fidget-spinner.github.io)

概要

  • CPython JIT が目標より早くパフォーマンス向上を達成
  • コミュニティ主導 とチームワークが成功要因
  • 技術的転換点 はトレース記録や参照カウント削減
  • インフラ整備 と日々のフィードバックの重要性
  • 人との交流 や運の要素も大きな役割

CPython JITの進捗と成果（2026年3月時点）

  • macOS AArch64 でJITはインタプリタ比約11-12%高速化
  • x86_64 Linux でも標準インタプリタ比5-6%高速化
  • 3.15 alpha JIT の数値は幾何平均・暫定値
  • パフォーマンス幅 は20%低下から100%以上の高速化まで
  • free-threading 対応は3.15/3.16で目指す
  • JIT開発 は一時困難だったが、再び軌道に乗る

JITプロジェクトの苦難と転機

  • 3.13/3.14 JIT はほぼ速度向上なし、むしろ遅かった
  • Faster CPythonチーム は資金提供者を失い、未来が不透明に
  • 主要貢献者 （Savannah Ostrowski, Mark Shannon, Diego Russo, Brandt Bucher, Ken Jinなど）が継続
  • 運とタイミング、適切な人材が揃ったことが成功の鍵
  • 貢献者拡大 のため、作業分割と明確な手順書を用意

コミュニティ主導による開発体制強化

  • バス係数低減 を目指し、各段階で2名以上のアクティブメンバー配置
  • 中間処理（middle-end） の貢献者が2名から4名に増加
  • Brandt による問題分割と「最適化タスクの細分化」
  • 新規貢献者 が参加しやすい環境整備
  • 11名の貢献者 がインタプリタ命令の変換作業に参加
  • 成果の可視化 と達成の祝福がモチベーション向上に寄与

技術的ブレークスルーと幸運

  • トレース記録型JIT への転換が大きな効果
    • Brandt の提案から始まり、初期は失敗だったが設計変更で成功
    • dual dispatch 方式でインタプリタの肥大化を回避
    • JITコードカバレッジ が50%増加し、最適化の効果が倍増
  • 参照カウント削減 の最適化
    • Matt Page の先行研究を基に、分岐削減で大幅な高速化
    • 教育的価値 も高く、新規貢献者の学習機会となる

インフラと日常的なフィードバック

  • Savannah が実質一人でインフラを担当
  • 4台のマシン で日常的なJITパフォーマンス計測
  • パフォーマンス回帰 の早期発見と最適化効果の可視化
  • ARM対応 やプロファイラ対応など多様な技術課題にも挑戦

人とのつながりと学び

  • PyPy 開発者CF Bolz-Tereickとの交流
  • Max Bernstein らとのコンパイラ談話でモチベーション維持
  • 他プロジェクト参照 による視野拡大と技術力向上
  • 知識やアイデアの共有 がプロジェクト成功に不可欠

結論：人と運がJITを動かす

  • 人の力 と 幸運 がCPython JITの進化を支える
  • JIT go brrr （JITが速く動く！）

Hackerたちの意見

まだ適切なフリースレッドサポートはないけど、3.15/3.16でそれを目指してるんだ。JITは今、軌道に戻ったよ。最近、フリースレッドを実装してエコシステムを通じて修正を加えることについてのインタビューを読んだんだけど、彼は「3.16か3.17ではフリースレッドビルドだけになることを願っている」って言ってた。JITにもそれが適用されるべきなのか、JITとインタプリタの関係がどうなるのか気になるな。

└

フリースレッディングはパフォーマンスを悪化させるだけで、助けにはならないと思ってるし、Pythonはそれをやめるべきだね。1%のユーザーのためにスレッドセーフなコードをあちこちに書かなきゃいけないのはおかしいよ。サブインタープリターが使えない理由があるにしてもね。

PyPyにはすでにJITコンパイラがあるんじゃないの？なんでそれを使わないの？

└

確か、PyPyは全てのCPython拡張をサポートしてないから、純粋なPythonコードは多分（ほぼ確実に）問題なく動くけど、他のものはほとんど期待できないと思う。PyPyは3.11までしかサポートしてないんじゃなかったっけ？

└

PyPyはもう機能してないみたいだから。しばらく更新されてないよ。例えば、ここを見てみて：https://github.com/numpy/numpy/issues/30416。新しいPythonバージョンとの互換性のために更新されてないんだ。

└

なんでリファレンス実装にJITを追加しないべきなの？他の実装にすでにあるからって理由にはならないよ。それはCPythonにすでに存在するからリスト内包表記をスキップするようなもんだ。

└

流行だった時にPyPyやPEP 399を支持することが大事だって騒いでた人たちが、今は企業から「PyPyなんて関係ない」って言われてるのが面白いよね。CPythonは今流行ってるものや、雇用主が求めるもの、利益が出るものにしか動かないんだ。

└

PyPyは資金や貢献者が足りなくて、メンテナンスモードに制限されてるんだ。過去には、少数の貢献者や資金が「マイナー」なPyPyのバージョンを推進するのに役立ったと思う。PSFが捨てた連邦資金をPyPyが受け取れなかったのは残念だね。

└

PyPyはCPythonじゃないからね。多くのPythonコードはまだCPythonの内部やC拡張、デバッガー、変なプラットフォームの挙動に依存してるから、PyPyはそのギャップがサポートの問題になるまで動くんだ。JITはホットループでは役立つけど、混合ワークロードの場合、ウォームアップコストや互換性の問題があって、ほとんどのチームは最初に依存関係がターゲットにしてるインタープリターを使い続けるんだよね。

JITに関することを把握するためにPRやイシューのトラッカーを時々チェックしてるけど、高レベルの議論がどこで行われてるのか見たことがない。イシューやPRはいつも詳細に飛び込んじゃうから。トレース投影と記録の違いについての高レベルの紹介や例がどこかにある？ググるとCPythonのイシュートラッカーが最初に出てくることが多いし、リポジトリのjit.mdは比較的シンプルで、あまり更新されてない :( 同じように、参照カウントの排除についても完全には理解してない。コード生成の違いは見たことあるけど、コード生成はビルド時に行われるから、各オペコードが削除されたインクリフやデクリフありなしで2つ（またはそれ以上？）のステンシルに分かれる可能性があるってこと？オペコードとその専門的なバリエーションがこんなにたくさんある中で、今はどれくらいのステンシルがあるんだろう？

└

PEPを見てみるといいかも。自分はこのトピックを深く掘り下げてないけど、関連してるっぽいよ：https://peps.python.org/pep-0744/

└

更新: 質問を誤解してた :-/ これ無視しても大丈夫だよ。コンパイラで遊ぶのが好きだから、ちょっと説明できるかも。みんなのために簡単に説明するね（スタックは無視するけど）: Pythonで関数間でオブジェクトが渡されるとき、コピーされるんじゃなくて、オブジェクトのメモリアドレスへの参照が送られるんだ。この参照はオブジェクトのデータへのポインタみたいなもので、オブジェクトのメモリアドレスが書かれた付箋みたいな感じ。関数が参照を使って戻るたびに、その付箋を捨てることを想像してみて。オブジェクトがゼロの参照になると、メモリから解放されて再利用できるんだ。だから、参照の数、つまり「参照カウント」を常に正確に保つことは大事なんだ。これがメモリリークの原因になることが多いけど、スピードアップには結びつかないと思う（GCを置き換えるなら別だけど）。

Hacker Newsで議論の続きを見る