2026/03/18 3:37
Python 3.15 のJIT（Just‑In‑Timeコンパイラ）が再び順調に進んでいます。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
(すべての主要ポイントを取り入れています):**
CPython 3.15/3.16 JIT プロジェクトは、初期段階でパフォーマンスマイルストーンを達成しました。macOS AArch64 上では、JIT が tail‑calling インタプリタより約11〜12 %高速であり、x86_64 Linux では標準インタプリタを約5〜6 %上回っています。また、パフォーマンステストは幅広い結果を示しています。
unpack_sequence主な技術的進歩には次が含まれます：
- トレース記録：単一の「tracing」命令とデュアルディスパッチテーブルを使用し、インタプリタの肥大化を削減。Linux 上では約6 %遅延から約1〜2 %高速に改善しました。
- 参照カウントの除去：分岐除去最適化で、命令ごとのオーバーヘッドを削減し、貢献者にとって有益な学習機会を提供します。
JIT チームは 2025 年に主要スポンサーを失いましたが、コミュニティの監督によって努力が継続しています。コア貢献者には Savannah Ostrowski、Mark Shannon、Diego Russo、Brandt Bucher、Hai Zhu、Zheaoli、Tomas Roun、Reiden Ong、および Donghee Na が含まれます。中間レベルの貢献者数は 2 人から 4 人に増加しました。
Savannah の 4 台のマシンで毎日 JIT を実行し、パフォーマンスフィードバックを提供し、回帰を検出し、新しい最適化を検証します。スプリント計画（Cambridge コア スプリント）は、CPython 3.15 で 5 %高速な JIT、3.16 では 10 %、フリースレッディングサポートの追加、および JIT の各段階で活躍するメンテナーを 2 人ずつ確保することを目指しています。
これらの進歩により CPython は競争力を維持し、より広いコミュニティ参加を促進し、フリースレッディングなど将来の機能への土台を築いています。
本文
Ken Jin のブログ – 2026 年 3 月 17 日
(JIT パフォーマンスは 3 月 17 日（PST）時点のものです。インタープリターより低いほど良く、画像クレジット： https://doesjitgobrrr.com/ )
素晴らしいニュースです――macOS AArch64 では 1 年早く、x86_64 Linux では数か月早く、CPython の JIT が（非常に控えめな）パフォーマンス目標を達成しました。
3.15 α の JIT は macOS AArch64 上でインタープリターの tail‑calling より 11〜12 %速く、x86_64 Linux 上では標準インタープリターより 5〜6 %速いです。これらは幾何平均値であり暫定的なものです。実際には、20 % の遅延から 100 % を超える高速化まで幅があり（
unpack_sequenceこの成果は決して軽視できません。途中では JIT プロジェクトが意味ある高速化を生み出すかどうか疑問に思った時期もありました。簡単にまとめると、元々の CPython JIT はほとんど速度向上がありませんでした：8 か月前に 3.13 と 3.14 の JIT がインタープリターより遅いという記事を投稿したことがあります。その頃は Faster CPython チームも主要スポンサーから資金を失っていました。私はボランティアなので直接の影響は少なかったものの、そこに働く友人たちには大きな打撃があり、JIT の将来が不透明に思える瞬間が何度かありました。
3.13 と 3.14 から何が変わったのでしょう？
「失敗の瀬戸際から JIT を救った英雄譚」を語るつもりはありません。正直、現在の成功を多くは運に帰しています――時期・場所・人・賭けといった要素がすべて揃っていたことです。Savannah Ostrowski、Mark Shannon、Diego Russo、Brandt Bucher、そして私自身の 5 人のコア貢献者の誰かが欠けていたら、この成果は得られなかったと確信しています。他にも Hai Zhu、Zheaoli、Tomas Roun、Reiden Ong、Donghee Na といった活発な貢献者もいます。
ここでは JIT の「人」と運について掘り下げます。技術的詳細は別途記載しています。
Faster CPython チームが 2025 年に主要スポンサーを失った際、私はすぐにコミュニティ主導の継続案を提案しました。このアイデアがうまくいくかどうかは不確実でした。JIT は新規貢献者には手強いプロジェクトであり、多くの事前知識が必要とされるためです。
Cambridge で開催された CPython コアスプリントで、JIT のコアチームは集まり、3.15 までに JIT を 5 % 高速化し、3.16 では 10 % 高速化（さらにスレッド分離サポート）を目指す計画を立てました。
また、プロジェクトの健全性を保つためにバスファクターを低減することも重要でした。フロントエンド（region selector）、ミドルエンド（optimizer）、バックエンド（コード生成）の 3 段階でそれぞれ 2 名以上のアクティブメンテナーを確保したいと考えました。
以前はミドルエンドに活発な貢献者が 2 人しかおらず、現在では 4 人に増加しました。Hai Zhu と Reiden Ong を含めた非コア開発者も貴重で有能なメンバーと見なしています。
人材を惹きつける鍵は、典型的なソフトウェア工学の手法――複雑な課題を管理しやすい単位に分解することでした。Brandt は 3.14 で「最適化タスクをシンプルに切り出す」メガイシューを多数作成しました。「JIT のある指令語を最適化してみよう」といった課題です。私は Brandt のアイデアを取り入れ、3.15 で「インタープリターの指令語を簡単に最適化できる形へ変換する」という課題を立ち上げました。この課題はインタープリター指令語を JIT 最適化しやすい形式へ変換するもので、詳細な手順と明確な作業単位を提示したため、新規貢献者にとってハードルが低くなりました。結果として 11 名（私を含む）がこの課題に取り組み、インタープリター全体のほぼすべてを JIT 最適化しやすい形へ変換しました。
その他にも、人々を励まし小さな成果でも祝福する文化が功を奏しました。各 JIT PR は明確なアウトカムを持ち、貢献者に方向性を与えました。
コミュニティ主導の最適化活動は実を結びました。x86_64 Linux で JIT が 1 % 高速だったものが、期間中に 3〜4 % 高速へと改善しました（下図の青線参照）。
(画像クレジット： https://doesjitgobrrr.com/ )
パート 2: 運命的な賭け
トレース記録
再度、運が大きく関与しています。Cambridge のコアスプリントで Brandt が私に「JIT フロントエンドをトレーシング型へ書き直す」ことを提案しました。当初はそのアイデアを嫌っていましたが、ちょっとした反抗的な開発として試してみることに。
3 日でプロトタイプは完成し、テストスイートを通過させるには 1 か月の作業が必要でした。初期結果は悪く、x86_64 Linux 上で約 6 % 遅延でした。放棄寸前だったところに、Mark の提案を誤解したことで偶然良い選択が生まれました。
Mark はインタープリター内のディスパッチテーブルを「トレーシング版」として2 つ持たせることを推奨しました。私はそれをさらに極端に解釈し、トレーシング版では「すべての指令語が1 つの特別な指令語へ向けられる」構造を採用しました。これにより、インタープリターサイズが倍増して膨大なコンパイルコードを生む問題が解消されました。この仕組みを「デュアルディスパッチ」と呼んでいます。
トレース記録インタープリターの設計にはさらに多くの工夫があり、1 週間かけて最終的に高速化しました。初期は 6 % 遅延でしたが、デュアルディスパッチ導入後はほぼ速度向上なし、さらなる微調整で約 1.x % の高速化を達成。トレース版インタープリター自体は、特化型インタープリターより 3〜5 倍遅いと見積もっていますが、主要な動作は保持しつつほぼ干渉しません。
トレース記録の影響は計り知れず、JIT のコードカバレッジを約 50 % 増加させました。すべての将来最適化が約 50 % 効果が減少する可能性もありました（実際にはすべて同じコードが実行されるわけではありません）。
Brandt と Mark に感謝しなければなりません。
参照カウントの除去
もう一つの運命的な賭けは「参照カウント除去」を試みたことです。これは元々 Matt Page が CPython バイトコード最適化で行っていた作業で、詳細は前回のブログに記載しています。JIT されたコード内では、バイトコード最適化後でも参照カウント減算ごとに分岐が残っていました。私は「この分岐を除去できないか」と試み、結果として単一の分岐が大きなコストであることが判明しました。
また、この作業は並列化しやすく、インタープリターと JIT の仕組みを学ぶ良い教材になる点も魅力でした。Python 3.15 では主に手動リファクタリングとして進めましたが、これにより貢献者は必要な知識を無理なく習得できました。
パート 3: 素晴らしいチーム
Savannah はインフラストラクチャーの全体像を担う存在です。
彼女は JIT のインフラを一人で担当し、パフォーマンス数値を報告する仕組みを構築しました。毎日の JIT 実行がフィードバックループを劇的に改善し、回帰の検出と最適化効果の確認を可能にしています。
Mark は技術面で抜群です。
インターネット上で過度な称賛を受けているので、ここでは触れませんが、その貢献は計り知れません。
Diego は ARM ハードウェア向けの JIT を担当し、最近はプロファイラに優しい JIT の実装を始めました。
これは非常に難易度の高い課題です。
Brandt はマシンコードバックエンドの基盤を築き上げました。
彼がいなければ、新規貢献者はアセンブラを書かなければならず、参加意欲が下がっていたでしょう。
パート 4: 人との対話
人と話し合い、アイデアを共有することの重要性も強調したいです。CF Bolz‑Tereick に感謝します――PyPy の知識を多く学び、JIT 開発者として成長できました。彼の助けがなかったら、このプロジェクトへのモチベーションは失っていたでしょう。
また、Max Bernstein と友好的にコンパイラチャットを行っています。彼のおかげで長い間モチベーションを保てたと思います。Max は多作の執筆者で、親しみやすいコンパイラ専門家です。
アイデアは孤立したものではありません。数人のコンパイラ関係者と交流することで JIT 開発が上達しました。少なくとも PyPy を見ることで視野が広がりました。
結論
人材は不可欠であり、運を借りれば JIT は「brrr」と鳴ります。