潜在的なプロジェクトたち¶
以下は、 PyPy プロジェクトに真剣に興味を持っている潜在的な貢献者にとっては興味深いであろうプロジェクトのリストです。 それらはの殆どは以下のようなパターンを満たします。
- 中〜大規模
- スタンドアロンのプロジェクトとして定義される
- 積極的に活動していない
参加しようと思っている小さなプロジェクトがあるならば、 issue tracker を見たり、 irc.freenode.net の #pypy チャンネルで発言するか、 mailing list に書いてください。
このリストは、主に潜在的プロジェクトの概要を示します。このリストは定義ではありませんが、自身の改善案を思いつく場合は満足しています。 どのケースにおいても、もしあなたがいくつかのプロジェクトや PyPy に関する他の何かに取り組みたいと思うなら、 IRC で発言するか、 mailing list に書いてください。
Numpy の実装¶
これは一つのプロジェクトよりもプロジェクトコンテナの詳細です。 案としては以下のようなものがあります。
- 配列操作のための SSE を用いた自動ベクトル化、もしくは自動検出を用いないベクトル化の実装の実験
- メモリビューを実装するなどの numpy の改良
- fortran/C ライブラリのインタフェイス
jitviewer の改良¶
アプリケーションのパフォーマンス解析はいつもトリッキーです。 パフォーマンス解析のためには様々ツールがありますが、例えば jitviewer はその助けとなるものの一つです。
jitviewer は以下のスクリーンショットのように、 PyPy の JIT コンパイラによって生成されたコードを階層的な方法で見せるものです。
- ボトムレベルでは、コンパイルされたループの Python ソースが表示されます
- ソースコードの一行ごとに、対応する Python のバイトコードが表示されます
- 命令ごとに対応する JIT 操作が表示され、それは実際にバックエンドに送信され、コンパイルされます (例では i15 = i10 < 2000)
jitviewer は flask と jija2 を使った Web アプリケーションです。(クライアントサイドでは jQuery を使っています) もしあなたが Web 開発のすごいスキルを持っていて、 PyPy を助けたいのであれば最初に手をつけるのには最適なタスクでしょう。 jitviewer は PyPy の内部構造の深い知識を全く必要としないからです。
他の言語でのいくつかの作業¶
いくつかの言語が RPython 変換ツールチェインを利用して実装されています。 最も興味深いもののうちの一つが JavaScript 処理系 ですし、他にも schema や prolog などもあります。 その興味のあるプロジェクトで JIT 性能の改善や、様々な最適化の実験をおこないます。
様々なガーベジコレクション¶
PyPy は取り替え可能なガーベジコレクションの方針を持っています。 これが意味するところは、特殊な目的のために様々なガーベジコレクタを書くことや、一般的な目的のための様々な実験を行えるということです。
例えば
- ゲームに必要な最大停止時間の短さに特化したインクリメンタルなガーベジコレクタ
- モバイルデバイス用のメモリ使用量の少ないガーベジコレクタ
- 並列ガーベジコレクタ(多くの仕事があります)
などです。
GIL の除去¶
これは考えることの多い主要なタスクです。ただし、良い計画を考えられる限り、いくつかのサブプロジェクトに分けられます。
- マルチスレッド対応のガーベジコレクタ
- 同時実行に対処可能なよりよい RPython のプリミティブなデータ
- オブジェクトのロックを除去するために JIT をパスする
- (おそらく)インタプリタのロックを実装する
- あるいは、 Software Transactional Memory の研究
新しいベンチマークの紹介¶
通常新しいベンチマークの紹介は満足しています。 紹介する前に我々に相談してください。しかし、実際の Python コードや、まだ上がっていないものに関しては大凡歓迎します。 必要なのは、少なくともスタンドアロンかつパラメータなしで動かせるスクリプトです。 例えば (ベンチマークにはそれらを手に入れることが必要です!)
- hg
- sympy
などです。
RPython コンパイルのための LLVM バックエンドの(再)実験¶
我々は既にLLVM の上で PyPy を動かすことを試しました。 LLVM は我々が必要とするほどには枯れていませんでした。 その状況は既に変わっている可能性があり、静的コンパイルのための LLVM バックエンドを復活させる(もしくは新しく書きなおす)ことは良いプロジェクトになります。
- (一方で、 C コードの生成に clang は clang を使用すれば十分であるかもしれません。
- それには、いわゆる “asmgcc GC root finder” という重い問題があります。 私の考えでは (arigo)、とてもポータブルで、別のもの(“shadowstack GC ルート探索)の最適化に挑戦するよりも間違いなく良いプロジェクトになるでしょう。これまでのところ、PyPy に 7% 程度の速度低下をもたらします。)
組み込み PyPy¶
制限された C API を持つ PyPy を組み込むことは役立つでしょう。 しかしここに EuroPython での生討論の延長線上にあるとても面白い変形があります。 動的リンクライブラリのプレースホルダとして使える汎用の “libpypy.so” を持つことができます。 ロードされるとき、それは (ctypes 経由で)エクスポートされたいインタフェイスをインストールする .py モジュールを実行します。 これは、.so ファイルをロードしたい様々なアプリケーションからインポートされる一つのファイルにまとまった汎用的な .so ファイルを私たちに与えるでしょう。