ブログ/記事一覧/Python 3.15 JIT、軌道に復帰 ― macOSで12%、Linuxで6%の高速化を達成
python-315-jit-back-on-track-cover

Python 3.15 JIT、軌道に復帰 ― macOSで12%、Linuxで6%の高速化を達成

Python 3.13で「インタプリタより遅い」と酷評されたJITコンパイラが、3.15でmacOS 12%・Linux 6%の高速化を達成。Microsoft資金打ち切りを乗り越えた逆転劇の全容

ニュース
kkm-horikawa

kkm

Backend Engineer / AWS / Django

2026.03.185 min10 views

Python 3.15のJITが、ついにインタプリタより速くなった

macOS AArch64で11〜12%の高速化。x86-64 Linuxで5〜6%の高速化。Windows MSVC 18環境では15〜20%のスピードアップ

数字だけ見ると地味に思えるかもしれません。しかしこの数字の裏には、「30か月かけてインタプリタより遅いJIT」という絶望的な状況からの逆転劇があります。

CPythonコア開発者のKen Jin氏は、こう振り返っています。「JITプロジェクトが意味のある高速化を生み出せるのか疑わしかった」。Python 3.15(現在アルファ版)は、その疑念を払拭する成果を出しました。

「本当に意味があるのか」― 30か月の苦闘

PythonにJITコンパイラを導入するプロジェクトは、2023年10月に正式に始まりました。Brandt Bucher氏が提案した「copy-and-patch JIT」がPython 3.13に実験的機能として搭載されたのが出発点です。

しかし結果は厳しいものでした。

「CPython 3.13のJITは、インタプリタより遅いか、せいぜい同等程度の範囲に収まっている」
― Ken Jin氏、DevClass取材(2025年7月)

JITコンパイラとは、プログラムの実行中に「よく使われる部分」を機械語(マシンコード)に変換して高速化する技術です。JavaやJavaScript(V8エンジン)では標準的に使われていますが、Pythonでは長らく実現されていませんでした。

Python 3.13で導入された初期のJITは、まだ変換できるコードの範囲が限られており、JIT自体のオーバーヘッド(準備や最適化にかかるコスト)がメリットを上回ってしまう状況でした。Python 3.14でもほとんど改善は見られず、プロジェクトの存続そのものが危ぶまれました。

追い打ちをかけるように、2025年5月にはMicrosoftがFaster CPythonプロジェクトへの資金提供を打ち切りました。JIT自体はコミュニティ主導のプロジェクトでしたが、Python高速化の機運全体に冷や水を浴びせる出来事でした。危機的な時期には、JITに取り組む開発者はKen Jin氏ただ一人になっていたこともあったと言います。

何が変わったのか ― 4つの技術的ブレイクスルー

Python 3.15のJITが「速くなった」のは偶然ではありません。公式のWhat's NewKen Jin氏のブログから、主要な改善点を整理します。

1. トレーシングフロントエンドの刷新

これが最大の変化です。3.14まではJITが最適化する「コードの範囲」を推定していましたが、3.15では実行パスを実際に記録する方式に転換しました。

料理に例えるなら、「たぶんこの材料が必要だろう」と見積もっていたのが、「実際に使った材料だけを買う」に変わったようなものです。これにより対応できるバイトコード操作とコントロールフローが大幅に拡張されました。

Pythonオブジェクトの生成、オーバーロード操作、ジェネレータも部分的にサポート。JITコードカバレッジが50%向上しました。

2. レジスタ割り当ての導入

JITのオプティマイザに基本的なレジスタ割り当てが追加されました。CPUのレジスタ(超高速な一時記憶領域)を直接使うことで、メモリの読み書きを削減します。

これまではスタック(メモリ上の領域)を経由していた操作が、レジスタで直接処理されるようになり、より効率的なマシンコードが生成されます。

3. 参照カウントの削減

Pythonはオブジェクトの参照数を数えてメモリ管理を行っています。この「参照カウント」の増減操作は、ほぼすべてのPython操作で発生するため、コスト削減の効果が絶大です。

Ken Jin氏によると、「たった1つの分岐を削除するだけで大きなパフォーマンス改善につながった」とのことです。

4. LLVM 21 + 機械語コード生成の改善

ビルド時のコード生成にLLVM 21を採用。さらにx86-64とAArch64の両プラットフォームで機械語の品質が向上し、メモリ使用量も削減されました。

エンドユーザーがLLVMをインストールする必要はありません。ビルド時にのみ使用されます。

JIT開発の軌跡 ― 絶望から希望へ

← スワイプで移動

ベンチマーク詳細 ― どんなコードが速くなるか

「12%高速化」は幾何平均の数字です。実際にはベンチマークによって20%遅くなるものから100%以上速くなるものまで大きな幅があります。

プラットフォーム幾何平均比較対象備考
macOS AArch64+11〜12%テールコーリングインタプリタApple Siliconでの結果
x86-64 Linux+5〜6%標準インタプリタpyperformanceスイート
Windows x86-64+15〜20%MSVC 18ビルドAMD Ryzen 7 5800X

特にWindows環境での改善が目立ちます。これはVisual Studio 2026(MSVC 18)のテールコーリングインタプリタとの組み合わせで、大規模な純Pythonライブラリで14%、長時間実行の小規模スクリプトで40%もの改善が報告されています。

JITが得意なのは、純粋なPythonコードでループや計算を多用する処理です。逆に、C拡張を多用するNumPyやPandasのようなライブラリは、そもそも重い処理がC側で行われているため、JITの恩恵は限定的です。

JITが「遅くなる」ケースとは?

JITにはオーバーヘッドがあります。トレース(実行パスの記録)、最適化、機械語生成にはCPU時間を消費します。短時間で終了するスクリプトや、JITが最適化できないパターン(C拡張の呼び出しが大半を占めるコード等)では、このオーバーヘッドがメリットを上回ることがあります。

ただし3.15ではこの「遅くなるケース」が大幅に減少しており、ほとんどのベンチマークでプラスかイーブンに収まっているとのことです。

まだ「実験的」だが、光は見えた

重要な注意点があります。Python 3.15のJITは依然として実験的機能です。利用するにはビルド時に --enable-experimental-jit フラグを指定する必要があり、デフォルトでは無効のままです。

しかし、プロジェクトの状態は劇的に改善しています。

開発体制の変化

  • Before Ken Jin氏ただ一人が開発
  • After  Savannah、Tomáš、Diegoら複数の貢献者が参加

今後のロードマップ

  • 3.15: さらなる最適化の追加
  • 3.15/3.16: フリースレッド対応
  • 将来: デフォルト有効化を目指す

Ken Jin氏が2年間の振り返りで強調しているのは、JITの設計を「教えやすさ」重視で進めたことです。トレーシングベースのアーキテクチャを選んだことで、コンパイラの専門家でなくてもJITに貢献できるようになりました。結果として、プロジェクトに参加する開発者が増え、並列で改善を進められる体制が整ったのです。

Python 3.15の正式リリースは2026年10月を予定しています。現在はアルファ版(3.15a7)で、今後さらにベンチマーク結果が改善される可能性もあります。公式ドキュメントにも「These results are not yet final(これらの結果はまだ最終版ではない)」と記されています。

「遅いJIT」から「速いJIT」へ

「Pythonは遅い」。これは何年も言われ続けてきた定型句です。そしてJITプロジェクトが始まったとき、多くの人が「ついにPythonも速くなるのか」と期待しました。その後に来たのは「JITを入れたのにまだ遅い」という落胆。

でもこの物語、どこかで聞いたことがありませんか。

JavaScriptのV8エンジンも、初期のJITは不安定で遅く、何年もかけてチューニングを重ねて今の高速なエンジンになりました。LuaJITも同様の道を辿っています。「最初から速いJIT」など存在しないのです。

Python 3.15のJITは、まだ「速い」と胸を張れる段階ではないかもしれません。しかし「遅くない」ところまでは確実に来ました。Microsoft の資金が消え、開発者が一人になり、「意味があるのか」と疑われながらも、コードを書き続けた人たちがいたということです。

ロッキーが序盤でボコボコにされてから立ち上がるように、Python JITもようやくラウンド後半に差し掛かったところです。12%のスピードアップは、まだ逆転KOではない。でも、観客が立ち上がり始めるには十分な一撃でしょう。

参照元