Pythonの実験的JIT、メンテナーがPEP撤回で事実上の終幕
Python's experimental JIT to be removed
2024年にCPython 3.13へ実験的に導入されたJITコンパイラが、事実上の終焉を迎えた。Python steering councilが標準トラックのPEP提出を求めたのに対し、メンテナーはPEP 836を起草したものの、サポート計画や性能基準の具体性不足を指摘され、10月19日に撤回。mainブランチからの削除が近く行われる見通しだ。
Steering Councilがこの規模の提案に高い基準を設けるのは当然であり、現行版を前に進めるだけの個人的な余力が我々にはないと感じている。
HNでの議論
153- adrian17
残念だ。時々この作業を追いかけていた。
一方では、SCが新しいPEPを要求するまでは、JITの作業は本当にハイギアで進んでいるように見えた。また、JITの希望の一部には、free threadingによる性能ペナルティに対抗できるという期待があったように思うので、それも残念だ。
他方で、（私には）得られたすべての凝った（そして間違いなくクールな）最適化——自動参照カウント操作の除去、新しい型ベースの特殊化、インプレース算術演算——を考えても、マクロベンチマークの利益はJITとしてはそれほど興奮するものではなかった。もっと多くの可能性は間違いなくある。整数のアンボクシングのようなさらに凝った最適化でね。しかし複雑さは増すばかりだ。
> PEPは、JITを有効にした場合のユーザーに見える違いについて「過度に楽観的」だったと述べていた。
JITは技術的にはインタプリタループ自体と同じソースから生成されるので、元々違いは極めて起こりにくかった。しかし、JIT専用の新しいパスや最適化が導入されるにつれてリスクは上がり続けたのだろう。
そして政治的に言えば、SCの理由は「このサイドプロジェクトはほとんど偶然にメインブランチに入り込み、それ以来監督なしで煮込まれ続け、安定化の見込みがない」というだけだったように思う。最新のPEPもおそらくまだ曖昧すぎて、「さらに煮込みに追加できるものはこれだ」という話が多かった——だからSCが満足しなかったのも理解できる。
- rich_sasha
代わりにこんなアイデアはどうだろう（もう存在するかもしれない）。インラインでCythonを書くためのデコレータを許可する。これで問題の90%は解決すると思う。初回実行時、あるいは積極的に、デコレートされた関数をコンパイルする。要するに、CythonがJITで、ユーザーが明示的に有効化するのだ。
こうすれば、Python風の言語で、適切なC速度のインライン関数を簡単に書ける。
これなしでCythonをほとんど使わない理由：
- 未修飾のPythonコードをCythonで実行するとしばしば速くなるが、それほどでもない。50%程度が経験則だ。
- しかしCythonとPythonでは開発スタイルが大きく異なり、インピーダンスが大きい。例えばリロードがうまく機能せず、プロファイリングも違い、ビルドディレクトリとデプロイ時のビルドステップが必要など。
- Cythonそのものは十分に違い、直感的でないとさえ言えるので、これらすべてを揃える必要があるなら、関数をRustでラップした方がましだ。
このようなデコレータがあれば、必要に応じて物事を速くする低摩擦の方法が得られ、あらゆる面白いCythonを使ってはるかに速くする余地もあり、しかもPython風のセマンティクス、特に「開発セマンティクス」を保てる。
Cythonは間違いなくPythonのスーパーセットだったので、言語の変更が必要だろう。その構文の一部は整理されたと思うが、まだ厳密なスーパーセットかもしれない。
- PathOfEclipse
PythonのJIT実験はいくつ失敗したのだろう？興味深いのは、RubyはおそらくPythonより最適化が難しいのに、Rubyにはずっと前からJITがあることだ。ベースのPythonがベースのRubyより最適化されているので、JITによる増分変化が大きくないのだろうか？また、JavaScriptは最適化が難しいはずだが、JITがある。ただそれは資金の問題かもしれない。JavaScriptを最適化する金とインセンティブははるかに多いのだろう。
- graemep
理由を見れば良い判断のように思える：https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to...
Pythonのパフォーマンスに対処する方法はすでにたくさんある（パフォーマンスが重要ならPythonが良い選択かどうかはさておき）。Cython、Numba、Pypy、C拡張などだ。
- xx_ns
技術的にエキサイティングな新機能が、本質的には官僚主義（そして開発者の個人的な余力の不足）のせいで一部殺されるのは残念だ。一方で、PEPポリシーへの厳格な遵守とそれに伴うすべての官僚主義こそが、良くも悪くもPythonを素晴らしい言語にしているのは確かだと言える。
技術的な反対意見に価値がなかったわけではない、おそらく大いにある。デバッガとインストルメンテーションのサポートとメンテナンス作業はそれ自体かなり苦痛に聞こえる。
- mike_hearn
CPythonにとって悲しい日だが、Pythonにとって悲しい日である必要はない。高度なJITコンパイラを備えた、完全にメンテナンスされたPython 3.13の実装がある。Pythonがウォームアップすれば、4倍以上速くなることもある（プログラムが何をしているかによる）。その実装はGraalPyと呼ばれ、JVM上に構築されている：
Chromeに少し似ていて、完全にオープンソースのバージョンと、いくつかの追加機能を備えたプロプライエタリバージョンがあるが、後者はオープンソースでも商用でも完全に無料で使える（有料で再配布はできない）。だから使った方がいい。
他にも興味深い機能がある
• スケーラブルでポーズなしのGC
• Pythonプログラムの単一バイナリ配布（Goのように）
• Java、JavaScript、Kotlin、Ruby、その他のTruffle言語を含む他言語との凝った最適化された相互運用
• ネイティブ拡張をサポート。SciPy、NumPy、PyTorch、Pandasなどの一般的なライブラリでテスト済みで動作する：https://graalpy.org/python-developers/compatibility/
• GILフリーモードに取り組んでいる
最近、GraalPyでのみ動作するPythonの新しいWebフレームワークPyronaut（https://pyronaut.io/）がリリースされた。JVM相互運用を利用してMicronautフレームワークを公開している。Micronautは知っている人にはSpringに似ている。JITとよく最適化されたベースライブラリのおかげで非常に高速に動作し、FastAPI+Granianより約3倍、Flask+Gunicornより7倍速く、機能もはるかに多い。
- pansa2
> 現在のバージョンを前に進める個人的な余力がないと感じている
JITの開発者は、MicrosoftでFaster CPythonに取り組んでいた人たちと同じなのだろうか？JITがフルタイムの仕事から趣味のプロジェクトになった今、同じ量のエネルギーをJITに注げないのは驚きではない。
- kannanvijayan
ここで技術的なホットテイクを吐き出そう。
Pythonは成熟したプロダクション言語で、多くのユーザーがいる。巨大になる前から——私が大学にいた20年前でさえ——Python拡張モジュール（私の場合はGNU readline）に小さな後方互換API変更を入れるには、そのAPI変更が必要だとGvRを個人的に説得する必要があった。
私が見てきたPythonのJITの試みはどれも、最初のパスで深く切り込みすぎ、スコープを大きくしすぎている。
JITによるPythonパフォーマンス最適化の成功例は、まずオブジェクトプロパティアクセスとメソッドディスパッチを最適化するための100%セマンティクス互換の隠れ型モデルから始まるべきだと信じている。
ほとんどの動的言語JITにおける最大のパフォーマンス差はそこから来るのであって、バイトコード操作のガードを最適化したり、マシンコードにコンパイルしたりすることからではない。ハッシュテーブルルックアップを定数時間のガード+オフセットルックアップに変換することから来るのだ。
隠れ型モデルも難物だ。様々な`__*__`メソッドを介して非常に動的な振る舞いをするdictセマンティクスを保持する必要があり、スコープ付き名前ルックアップは最も一般的で独自のエキゾチックな振る舞いをするので、エキゾチックなスコープオブジェクトを扱う必要がある（Pythonが呼び出し元のスコープを限られた方法で検査する能力を提供していたのを覚えている）。