合併と買収

静かに、そしていつの間にか、Unladen Swallowについて別の投稿を書き、「静かに、そしていつの間にか」という言葉で再び始めたいという要望がありました。 そしてこの場合、これらの言葉はもっと適切になります...



私たちは皆、「ツバメ」に関するニュースを見逃しています。 プロジェクトのメインページには、次の四半期リリースのリリースに関する最新のニュースレポート-昨年10月の2009Q3があります。 開発者自身からのニュースがHabréを流れており、Google内でPythonを使用する見込みについて疑問を投げかけています。したがって、Googleは「飲み込み」に関心を持っています。 すべてが悪くて喜びがない、それは私たちにPythonの適切なJITコンパイラを見ないように思えます...



しかし、違います。 今日、偶然OFTCの#UNladenswallowチャンネルに行くと、 私の帽子が飛び去り、碑文で迎えられました: PEP 3146が承認されました! ちなみに、このPEP 3146は、CPythonとのUnladen Swallow統合計画の説明であり、現在はAccepted / Standards Trackステータスになっています。



言い換えると、静かに、そしていつの間にか(ほとんど!)Unladen Swallowチームは公式のCPythonリポジトリへのコミットアクセスを許可され、特別なブランチpy3k-jitが作成されました 。そして、Python 2.6との互換モードのコードベースは、Python 3.xとの互換モードに徐々に移行されました。 徐々に、すべての問題が解決されると(そして、多くの問題があります-たとえば、このまさにタスクのフレームワーク内で、共有リンクモードでの機能を改善するためにLLVM自体で作業する予定です。それ以外の場合は、静的にリンクされたLLVM Unladen Swallowで組み立てられ、12 1.5 MBのCPythonに対してメガバイト-それは一種の過酷です)、標準の説明のPython-Versionマークによって判断すると、Python 3.3領域では、このコードの完全なフリーズがCPythonメインブランチで行われます。



ところで、LLVMサポートを追加するとC ++コードがCPythonにもたらされることは興味深いです-その名前が示すように、CPythonは純粋なCで開発された前に、LLVM機能を完全に使用するために使用することに決めましたC ++。 ただし、この問題も解決されており、CPythonでUnladen Swallowコードを採用する場合の問題にはなりませんでした。



明らかに、これはもっぱら「未来のためのゲーム」です-さまざまなテストによると、Unladen Swallowは計画された加速を平均5倍も表示せず、30-50-100%(hehe)のオーダーの勝利を与えます。 それにもかかわらず、開発者の口調によって、最近彼らは主に組織および統合タスクに従事しており、LLVMの実際の最適化機能にほとんど触れていないことは明らかです配信)。 論理的に-後で最もおいしい。 興味深い未来が私たちを待っています。



All Articles