- 今回公開された Python 3.14 は、これまでの CPython バージョンの中で最も高速な性能を示した
- シングルスレッドでは 3.14 が 3.13 比で 約 27% 改善し、JIT の性能向上はわずかで、Free-threading インタープリタはシングルスレッドでやや遅い
- マルチスレッドでは FT インタープリタが GIL 削除の効果により Fibonacci で 3.1 倍、バブルソートで 2 倍程度の高速化を示し、CPU 集約型マルチスレッドで有効
- 結論として 3.14 が CPython の中で最速であり、3.11 以上を推奨、Pypy は依然として非常に高速で、JIT は 成熟度の向上が必要
ベンチマークの前提と限界
- Python 3.14 の正式リリース直後、複数バージョンの Python および他言語との 性能ベンチマーク結果が共有された
- このテストは 純粋な Python コードのみで書かれた単純な再帰（フィボナッチ）と反復（バブルソート）関数で実施
- 実際の開発現場では C/C++/Rust などのネイティブコードと組み合わせて使うことが多いため、この結果は 実際の状況に 1:1 で対応するものではない
テストマトリクス
- テスト環境
- Python 6 バージョン（3.9〜3.14）、Pypy、Node.js、Rust を含む
- Python インタープリタ: 標準(Standard)、JIT、Free-threading（それぞれ 3.13 以上）
- テストスクリプト: フィボナッチ(fibo.py)、バブルソート(bubble.py)
- スレッドモード: シングルスレッド、4 スレッド
- テストマシン: Linux（Framework i5）、macOS（M2）
- Node.js、Rust のバージョンも参考対象としてあわせて比較
テストスクリプト
- フィボナッチ(fibo.py): 再帰構造を使用し、
fibo(40) を各環境で実行
- バブルソート(bubble.py): 10,000 個のランダムな数値をソート
- 各テストは 3 回繰り返して平均値を算出
- テストコードは GitHub リポジトリ で公開
Benchmark #1: フィボナッチ（シングルスレッド）
- Python 3.14 は 3.13 比で 約 27% 向上した速度（6.59 秒 vs 8.26 秒）を記録
- 3.11 バージョンから「非常に遅い」から「多少は遅くない」へと移行した
- Pypy は 3.14 より約 5 倍速く、Node.js と同等、Rust は圧倒的に最速
- Free-threading はシングルスレッドでは標準バージョンより依然として遅いが、3.14 で速度差は縮小（91% 水準）
JIT、Free-threading インタープリタ
- JIT はこの再帰関数構造では 体感できる性能向上はなし
- Free-threading はシングルスレッドではむしろ少し遅い結果
- JIT の性能向上の限界は関数構造によって異なる可能性がある
Benchmark #2: バブルソート（シングルスレッド）
- Python 3.14 は 3.11 よりわずかに高速だが、差はフィボナッチより小さい（3.14: 2.18 秒、3.11: 2.48 秒）
- Pypy は 3.14 より約 18 倍速い
- JIT は Linux 環境ではやや速い場合もあるが、macOS ではほとんど差がない
Benchmark #3: フィボナッチ（マルチスレッド）
- 標準インタープリタでは GIL(Global Interpreter Lock) のため、スレッド数を増やしても期待ほど高速にならない
- Free-threading インタープリタ（3.14）は標準比で 3.1 倍高速化
- JIT の影響はほとんど確認できなかった
- Pypy の結果のみ測定され、Node.js/Rust はこのテストでは比較していない
Benchmark #4: バブルソート（マルチスレッド）
- Free-threading（3.14 FT）は標準（3.14）比で 2 倍速い結果となった（特に CPU 集約型作業で利点が際立つ）
- JIT に明確な性能優位はない
- Mac の Free-threading 性能が目立った
結論
- CPython 3.14 は現行の CPython の中で最速の性能を示した
- アップグレードが難しい場合は 3.11 以上のバージョン使用を推奨
- JIT インタープリタは実際に体感できる速度向上がわずかだった
- Free-threading インタープリタはマルチスレッドの CPU 集約型状況で明確な利点がある
- Pypy は圧倒的に高速で、さらに探求する価値が大きい
その他
- 結果はさまざまな環境変数によって変わる可能性があるため、直接ベンチマークして確認することを推奨
- 詳細およびコードは GitHub リポジトリを参照可能
1件のコメント
Hacker News の意見
人生を変えてくれた人の話をしたい。Flask mega tutorial を通じて初めてのWebサイトを作り、公開直前に Flask で壊れたファイルを処理する重要な部分で詰まったのだが、質問したところ Stack Overflow の回答で解決し、そのまますぐサイトに反映できた。その後サイトはものすごく広まった。参考までに回答へのリンクを残しておく stackoverflow link
Flask とは関係ないが、新しい Flask のロゴは本当に好きになれない。以前のロゴにはヴィンテージで手作り感のある雰囲気があったのに、新しいロゴはまるで高校生が WordArt でふざけて作った作品みたいだ。以前のロゴ, 新しいロゴ
もしかして君が作ったサイトは yout.com なのかと聞いてみたい。今でも Flask を使っているのか気になる
いつかまた vibe coding をして microphonetest.com が復活したら本当にうれしい
ベンチマークを書くときは、ループの中で時間を測って合計するようなやり方は避けたほうがいい。ループ全体の実行時間を測ってから反復回数で割るのがよい。計測そのものに伴うジッターで結果が歪む可能性がある
Python が 3.14 で TeX のように固定化されてしまわないか心配だ Reddit リンク
「止まらないでほしい」という意見を見て、Donald Knuth が変化よりも継続して同じ結果を出すシステムを重視している点が新鮮に感じられた。何もかもが数年で古くなる世界では、何か新しいものが出たからといって無条件に乗り換えなければならないという強迫観念は病的ですらあると思う。私たちが本当に100年使えるコードを書けない理由はない。コードは結局数学なのだから。何千年も前に発明された多項式を使っても時代遅れ扱いされないように、実証済みのものに留まる姿勢も必要だと思う。毎回新バージョンや新ツールにばかり執着しなくてもいい。変える理由のないコードを書いている人たちこそ本当に貢献している人たちだと思う
πthon に関するジョークに驚くほどよく合う状況だというコメント
Python のニュースが出るたびに、2025年になっても PyPy が依然として別路線であることが惜しく感じられる。GIL なしの Python が someday GIL なしの C FFI まで可能にしてくれるのか気になる。それは Python にとって本当に大きな助けになると思う
C FFI は昔から手動で GIL を解放できたので、それが具体的にどういう意味なのか正確に気になる
C 言語から出発して複数のコンパイラ実装から多様な方言が生まれるのは健全なエコシステムだと思う。実験と発展を促すからだ。PyPy と CPython の違いもそれほど大きいとは思わず、互換性も高い pypy compatibility guide
freethreading はまさにそのためのものだ。まだ多くの C FFI ライブラリが GIL なしで動作するようには変わっていないので、デフォルトで freethreading を使えないと理解している
Python は実験的な JIT を追加して、PyPy に一歩近づいたと言える。今後新しい JIT を自前で作るのか PyPy を取り込むのかは分からないが、PyPy から多くを学んだと信じている
こうした問題（別実装の体系を統合すること）が変わり得ると思うか聞いてみたい。Python がたまたま性能に悪影響を与える別の破壊的変更を導入するようなシナリオは、広い範囲のユーザーに害を及ぼすだろう。Python の組織が本当にそれを望むのか疑問だ
PyPy がマルチスレッドコードでも free threaded CPython より速いという点が興味深い
non-GIL への移行が非常にスムーズに進んでいるのが目を引く。2→3 のときと比べると、今回の移行は本当にすごい。標準の速度にすぐ到達した点にも期待が持てるし、非互換な要素も近いうちになくなることを願っている
手早く自分でベンチマークしてみたいなら fast_langton_ant リポジトリを勧める。
python3 server.py -s 10000000 -nのように実行すればよい折りたたみコメント機能が karma やほかの条件によって適用されるのか気になる。Miguel が助けてくれたエピソードがいちばん人気のある投稿なのが印象的だったが、本文に関係する話だけを見たいときに折りたたみ機能がないことに初めて気づいた
単純なループと整数演算だけを使うベンチマークで Python の現実的な使われ方を評価するのは無理があると思う。ハッシュマップや文字列処理のほうが実際のコードに近い。多くの Python ユーザーは数値演算を外部ライブラリに任せている
ベンチマークはどれも特定の基準で測るよう設計されるものだ。本人が記事の中で目的を説明しているので、気になるなら参照することを勧める
もっと徹底的に分析した記事ならよかったが、それでも自分の実際の使い方にはこの種のベンチマークのほうが合っている。自分の場合、ほとんどはモンテカルロシミュレーションや簡単な科学計算をさまざまな問題に対して繰り返し作る。使い捨てのシミュレーションに、わざわざ高速なアルゴリズムや不慣れなライブラリは使わない。ときどき10分かかっても構わない（たとえば scipy, numpy は主に使ってはいる）。前提条件の変更を何度も繰り返すので、できるだけ単純に進める。可読性とその場で書けるコードが重要で、最適化が甘くても問題ない（たとえばフィボナッチ、バブルソート、入れ子の for ループのようなもの）。もし本当に性能が必要なら cpp/zmp/pybind/numba で中身を自分で実装する
FastAPI エンドポイント呼び出しや numpy 計算のような一般的な例をベンチマークに含めるほうが、現実の Python 利用に近い。こうした部分は純粋な Python コードではないかもしれないが、実際には多くの人がそのように Python を使っている
tight loop と int 演算だけでベンチマークするのがどれほど現実的なのか疑問だ
新しい実験的な tail call interpreter（オプション
--with-tail-call-interp）がベンチマークに含まれていたのか気になる tail-call-interp 公式ドキュメント。テスト結果で言及がないので、おそらく含まれていなかったのではと推測している。tail call interpreter が既存のほかの実装とどのくらい違うのか比較してみたい--with-tail-call-interp）だった。最適化が再帰の tail call にも適用されるかは確信がないが、もし適用されているなら Fibonacci テストで性能向上が見えていたはずだ