インタビュー： Pythonの生みの親であるGuido van Rossum氏は先週、公式実装であるCPythonを4年で5倍高速化するプロジェクトを発表しました。今回、このプロジェクトの初期メンバー3人のうちの1人であるMark Shannon氏が、その目的と方法について語ります。
シャノン氏は、マイクロソフト傘下のGitHub傘下のコードセキュリティ分析企業Semmleでリサーチエンジニアを務めていたが、現在はマイクロソフトの契約社員としてCPythonの開発に携わっている。先週開催されたPython Language Summitで、ヴァン・ロッサム氏は、シャノン氏と同じくマイクロソフトのシニアソフトウェアエンジニアであるエリック・スノー氏と共に、マイクロソフトが資金提供する新チームの一員となり、CPythonの高速化を目指すと述べた。ヴァン・ロッサム氏はここで「シャノン計画」について言及し、3.11で2倍の高速化を実現し、4年後には5倍の高速化を目指すとしている。CPythonバージョン3.11は、2022年10月頃にリリースされる見込みだ。
これまでヴァン・ロッサム氏は、C言語で拡張機能を書いたり、JITコンパイルされたPyPyを使ったりするなど、パフォーマンスを向上させる方法は他にもたくさんあるため、CPythonの高速化はそれほど重要ではないと示唆していました。なぜ考えが変わったのでしょうか？
マーク・シャノン
「それについてはGuidoに聞いてもらう必要がありますが、ここ数年で機械学習におけるPythonの人気が爆発的に高まったためだと思います。つまり、利用できるリソースが増えたため、信頼性の低下などを心配することなく、パフォーマンスに投資できるということです」とシャノン氏はThe Regに語った。「これが私の見解です。」
シャノンは博士論文の一環としてHotPyというプロジェクトに取り組み、「一般的に最適化が難しいとされる言語の一部を実装し、それが機能することを証明した」。その後、HotPy2に取り組んだ。これは「それらのアイデアをCPythonに適用したもので、一応は機能したが、もはや現実的ではなかった」と彼は語る。その後、「すべては棚上げになった」と彼は付け加える。何が変わったのだろうか？昨年、彼はより多くの時間を割くことができ、Pythonの高速化計画を投稿した。そして「グイドがマイクロソフトで働き始めた際に、パフォーマンスについて調査しようと決めた」ことが、この新しいプロジェクトにつながった。
CPythonインタープリタはシンプルに保つべきだという議論についてはどうだろうか？「オープンソースプロジェクトとして、コードへのアクセス性は重要だと思います。だからといって、コードが単純である必要はありません。きちんと整理され、モジュール化され、ドキュメントが充実している必要があるのです」とシャノン氏は言う。「私たちは、このシンプルさを維持したいと考えています。」
ヴァン・ロッサム氏が新しいグループに参加しているということは、その成果が必ず公式CPythonに組み込まれることを意味するのだろうか？「絶対的な保証ではありません。オープンソース開発モデルに従っているので、すべての成果はコミットされ、レビューを経て、段階的にCPythonのメイン開発ブランチに組み入れられます。そのため、私たちは個別の大規模プロジェクトを抱えるのではなく、常にCPythonの改善に取り組んでいます。そのため、開発方法、あるいは多くの場合、作業の順序に制約が生じますが…それでも、公式CPythonに組み込まれることはほぼ確実です。もちろん、Guido氏の地位はプラスに働くでしょう」とシャノン氏は言う。
このグループの取り組みは、PyPy、FacebookのCinder、Pystonなど、Pythonを高速化する他のプロジェクトとどのように関連しているのでしょうか？「10年前に博士号を取得して以来、Pythonの最適化に取り組んできました」とシャノン氏は言います。「PyPyの人たちとは密接なコミュニケーションをとってきましたが、最近はそうではありません。常にアイデアの交換をしていますし、他のプロジェクトを見て、彼らが何をしてきたかを確認しています。コードをそのまま使うのは面倒なことが多いですが、開発されテストされたアイデアであれば、コードを書き直すのはそれほど大変な作業ではありません。彼らが何かを試してみてうまくいかなかったという情報は、私たちにとって貴重な情報となることが多いのです。」他のプロジェクトがコードをアップストリームするかどうかは、そのプロジェクト次第だとシャノン氏は付け加えます。
- Guido van Rossum は CPython を 3.11 で 2 倍高速化することを目指している
- より高速な Python の探求: Pyston がオープン ソースに戻り、Facebook が Cinder をリリース、それとも開発者は PyPy だけを使うべきでしょうか?
- Python、お誕生日おめでとう！今週30周年！簡単に学べて、適切な時に適切なツール
- 「バグの発見が修正よりはるかに速い」：GoogleがLinuxセキュリティ向上のためフルタイム開発者2名を支援
- IronPython を使用した .NET のクイック スクリプト
新しいプロジェクトが他の選択肢への関心を低下させるのではないかという疑問もあります。Cinderの場合、「特に時代遅れになるとは思いません。彼らはコードを可能な限り高速化し、他のことには関心を持たないのが彼らのやり方だからです」とシャノン氏は言います。「Pystonについても、Pystonの目標はよく似ていると思います。彼らと話し、彼らから学ぶことを喜んでいるのです。」
私たちは、この取り組みをデータサイエンス分野のPythonに重点を置くのか、それともウェブサイトのような汎用的なユースケースに重点を置くのかという問題について議論しました。「私たちの関心は、ウェブとデータサイエンスコミュニティの両方において、Python全般のパフォーマンスを向上させることです。当面はウェブに重点を置くことになるでしょうが、それはまず何を最適化できるか、そして何が実用的かという点に大きく関係しています。…特定のワークロードを優先すべきではない、つまり、あるユースケースが他のユースケースよりも不利になるようなことはすべきではない、というのが私たちの考え方です。」
MLのケースは異例だと彼は言います。「ディープマトリックス処理などは、テンソル演算処理装置などに特化したカスタム言語で記述する必要があります。Pythonは、モジュールモデルの読み込みなど、より高レベルのインタラクションを行うために使用されることが多く、そのワークロードはより『普通』です。ですから、私たちはその恩恵を受けることができるのです。」
大きな課題：後方互換性
Pythonの高速化における最大の課題は何でしょうか？「私たちが気づいていないかもしれない機能の後方互換性です。C APIは時間とともに進化してきたため、その一部では基盤となる動作を変更するのが非常に困難です」と彼は言います。「十分なAPIがない部分もあり、CPythonの内部構造をくまなく調べなければなりません。ツール、デバッガ、プロファイル、そして重要なCythonやNumPyスタックなどは、私たちが必ずしも認識していないCPythonの内部構造を利用しています」とシャノンは言います。「したがって、それらを変更するのは困難です…CPythonユーザーとの暗黙の契約、つまり変更できるものとできないものについては、あまり明確に定義されていません。状況は改善されていますが、例えば5年前にこれを試みていたら、もっと大きな問題になっていたでしょう。」
2や3と比較すると、それはほとんど死んでいる。誰もそんなことはしたくないからだ。
Python 3によってもたらされた後方互換性の問題はコミュニティにとって好ましくなかったため、高速だが互換性のない新しいバージョンが登場する可能性は低い。「Python 2やPython 3と比較されるものなら、Pythonはほぼ死んでいると言えるでしょう。誰もPythonを使いたくないからです」と彼は言う。
シャノン氏の計画では、JITコンパイラの使用が3.11以降に延期されたのはなぜでしょうか？「JITコンパイラは魔法の万能薬だと思われがちですが、そうではありません。JITコンパイラはエンジニアリングの一環であり、適切に設計・実装されていなければ機能しません。動的言語の最適化は、まず特化を行う必要があります。特化とは、想定される値と時間に合わせてこのコードを書き直すことです。これはインタープリタで行うことも、コンパイラで行うこともできますが、インタープリタで行う場合は、コンパイラで既に処理されているため、インタープリタの速度が向上します。そのため、先に特化を行う方が理にかなっているのです」と彼は主張します。
マイナープラットフォームにも問題があります。「あらゆる物理アーキテクチャに対応したJITコンパイラを開発するつもりはありません」と彼は言います。「一方、インタープリタの高速化や仮想マシンの改良は、あらゆるアーキテクチャで機能します。」
私たちにできることは大きく分けて3つあります。1つは、特殊化によってインタプリタ自体を高速化することです。もう1つは、データ構造とメモリレイアウトを改善して、キャッシュ効率を高め、現代のアーキテクチャに適合させることです。そして3つ目は、マシンコードへの変換、つまりジャストインタイムコンパイラです。この3つ目が、他の3つに依存しています。
CPythonのパフォーマンスに焦点を当てるのに、なぜこれほど長い時間がかかったのだろうか？「実際にはそれほど遅くないことも多いし、問題にもなりません」とシャノン氏はThe Regに語っている。一つの要因は、ネットワークよりもはるかに高速であるため、ボトルネックにならないことが多いことだ。もう一つの要因は、「Pythonはライブラリが非常によく調整されており、言語の他の部分とうまく連携するため、多くの基本的な操作が高速に実行される」ことだと彼は付け加える。「プログラムを書く際に、ディスクからファイルを読み込み、どこかに書き出したり、ネットワーク経由で送信したりする必要がある場合、Pythonでプログラムを書き、Cでプログラムを書くと、おそらくPythonプログラムの方が高速になるだろう。なぜなら、Pythonは簡単に書けるからだ。Cで書くには多くの労力が必要で、Pythonライブラリ自体がCで既にうまく書かれている部分を書き直すことになる。つまり、ユースケースによって異なるのだ。」
逆の例としては、パフォーマンスよりも生産性が重視される小さなプロジェクトが、パフォーマンスが極めて重要な巨大なコード ベースに成長することがあります。Facebook/Instagram (Cinder) や Dropbox (Pyston、その後 Go に変更) のようなプロジェクトが生まれています。
「私たちは人々がそれほど選択をしなくても済むようにしたいのです」とシャノンは言う。®
