オリジナル：Reid Kleckner- Unladen Swallow Retrospective
Unladen Swallow：回顧
私はPyConにいたときにこれを書き始めましたが、それ以来少しテキストを更新しています。 なるほど、ここで。 :)
明らかなように、Unladen Swallowを直接扱ったり、py3kに移植したりする人は誰もいません。 なんで？
顧客の興味の喪失
主な理由は、GoogleがUnladen Swallowの潜在的なユーザーを十分に見つけられなかったためです。 これにはいくつかの理由があります。
- GoogleのPythonコードの大部分では、高いパフォーマンスは必要ありません。 Pythonは主にツールとプロトタイピングに使用され、メインのエンドユーザーアプリケーションはJavaとC ++で記述されています。
- パフォーマンスが重要だった内部ユーザーは、Unladen Swallowを展開するための複雑すぎる要件に戸惑っていました。 彼らにとって、Unladen SwallowがCPythonの代わりになるだけでなく、新しいPython実装は既存の「ターンキー」実装を置き換える必要がありました。 ソースコードをCPythonに基づいて開発し、絶対ゼロから開発を開始しないと、この問題を回避できると考えました。CおよびSWIGラッパーのすべての拡張機能は、何も起こらなかったように機能し続けるからです。 ただし、以前のバージョンのCPythonからPython 2.6にアップグレードすることも複雑すぎました。
- 何らかの方法で、潜在的なユーザーはパフォーマンスの問題を解決する他の方法を見つけました。これは、展開するのにより便利であることが判明しました。
インターンシップが終了した後、私はUnladenをMITでの修士号のテーマにしようとしましたが、マネージャーは、当時達成された結果は良い見通しを約束するものではなく、私が適用したいコンセプトはもはやモダンとは見なされないと考えました。 主なメソッド（トランスレーターから： 最適化されていない実行プロセスの追跡に基づいて最適化されたコードを生成するメソッドを参照）フィードバックは既にSmalltalkのUrsHölzleによって実装され、トレースメソッドはAndreas Gilによって実装されました（コメント：実際、Andreas Gal） Javaの場合。 もちろん、これは他の誰も新しい方法を発明できないという意味ではありませんが、その時点で私は新鮮なアイデアを持っていませんでした。
自己利益の喪失
基本的に、上記のすべては2010年の第1四半期に検討されました。 空き時間にUnladenで作業することもできますが、それは異なります。
第一に、プロジェクトに単独で取り組むことは、特にあなたの作品にユーザーが含まれるかどうかが明らかでない場合、他の人と同じくらい楽しいことではありません。
第二に、私たちが興味を持っている主な理由の1つは、PyPyがC拡張やSWIGラップコードをサポートしようとさえしないと信じていたことです。 PyPyプロジェクトがこの方向に動き始めたことを知ったとき、私たちは非常に驚きました。 これにより、CPython用のプラグインJITの必要性が部分的に緩和されました。 さらに、プロジェクトが開始されたとき、PyPyは64ビットプラットフォームをまだサポートしていませんでしたが、時間の経過とともにこのサポートを追加しました。
そして最後に、私たちが読んだpython-devのコメントは私たちを安心させませんでした。 Unladen Swallowがpy3kに入ると、このコードはGoogleによってサポートされると想定されていましたが、これらの仮定はすでに根拠のないものでした。 コードが凍結された場合、デフォルトではJITがオフになり、1年後にはまれに使用されサポートが不足するため 、再度削除する必要があります。 新しいJITに興味を持った開発者はほとんどいませんでした。 コードを支配したことは一度もありませんでしたが、完了すれば、CPython開発者がそれを手に入れるよう促すことができると期待していました。
では、上記のすべての理由を考慮に入れると、誰もがUnladenを扱っていないことがわかりますが、何がわかりますか？
LLVMに関する結論
まず、LLVMを使用してJITコードを生成することの長所と短所を深く研究しました。 LLVMを使用するという最初の決定は、x86アセンブラを深く知らなかったために行われましたが、同時にx86、x86_64、および場合によってはARMの両方をサポートしたいと考えました。 psycoをリサイクルするオプションを検討しましたが、主にx86の詳細な知識が必要なため拒否しました。
残念ながら、現時点ではLLVMは静的オプティマイザーおよびバックエンドとしての使用に集中しています。 LLVMコードの生成と最適化は優れていますが、使用するには高価すぎます。 最適化は、静的なCライクな言語によって生成された中間コード表現で動作するには向きすぎます。 最も基本的なPython最適化手法では、以前の反復でプログラムがどのように機能したかについての高レベルのビューが必要です。これはLLVMでは困難でした。
コード生成で高レベルの表現がどのように適用されるかの例は、Pythonスタックでの作業の最適化です。 LLVMは、外部関数（つまり、実際には実行されないCPython環境）の呼び出し間でPythonスタックからの読み取りを最適化できません。 この問題を解決するために、ようやくエイリアスの分析を記述する必要がありました。これは、独自のコードジェネレーターを作成しない場合に発生する典型的な例です。
さらに、LLVMには他の制限が適用されます。 たとえば、LLVMは、PyPyが作業コードの検証ブランチからのオンザフライ出口を編集するために使用するバックパッチ（トランスレーターからのコード：動的コード変更）を真剣にサポートしていません。 これはかなりのメモリ消費を伴うかなり重要な要件ですが、GSOC内でのSteven Noonanの作業の結果によると、特にPyPyのメモリ消費量が多いことを考慮すると、後者について議論します。
さらに、LLVM JITとgdbの間のインターフェースを作成するために夏を過ごしました。 これは必要ではありませんでしたが、結果は有用なツールでした。 PyPyのデバッグに何が使用されているのかわかりませんが、経験を生かしてPyPyに適用できます。
結果
個人的には、このプロジェクトの作業を開始する前でも、コンパイラとオペレーティングシステムのコースを受講しましたが、作業中に得た経験により、膨大な新しいスキルが得られました。 私は今、gdbに精通しているので、自分でルールを決めて、gdbでgdbをデバッグしました。 現在、x86、コンパイラー最適化手法、JIT機能についてより多くのことを知っており、これをマスターの仕事で使用しています。
また、実際のPythonアプリケーションのマクロベンチマークセットを非常に誇りに思っています。これは現在、PyPyプロジェクトで積極的に使用されています： speed.pypy.org 。 私のすべてのPythonパフォーマンス関連のアクティビティの中で、それが最も有用であることが証明されています。 パフォーマンスの変化は、その出現前後の結果の変化によって簡単に認識されます。
また、LLVMにいくつかの利点をもたらし、ParrotやRubiniusなどの他のLLVMベースのJITプロジェクトを支援しました。 たとえば、JITが分析するコードの16メガバイトの制限を修正するのを手伝いました。 繰り返しますが、LLVM JIT用のgdbインターフェースがあります。 ジェフはまた、メモリリークを修正し、LLVMでCタイプを構築するためにTypeBuilderテンプレートを追加するだけでなく、生成されたJITコードにC関数を直接コンパイルできるように多くの時間を費やしました。
したがって、リソースが増えてプロジェクトが生き延びたとしても、それは素晴らしい経験をもたらし、LLVMにいくつかの利点をもたらし、非常に有用なベンチマークのセットを作成することができました。