よくある質問

モジュール/パッケージXYZはGraalPyで動作しますか。

状況によります。GraalPyの最初の目標は、管理されたGraalVM LLVMランタイムを使用してNumPyおよび関連パッケージを実行できることを示すことでした。GraalVMチームは、CPythonユニット・テストに合格する数を増やし、一般的なPyPIパッケージとの互換性を追跡し続けています。上位500個のPyPIパッケージのうち、現在、約50%がGraalPyのテストの大部分に合格しています。

GraalPyでJythonユース・ケースを置き換えることができますか。

可能ですが、Javaクラスをサブクラス化するPythonコードやjavax.script.ScriptEngineを介した使用がサポートされていないなど、いくつかの注意事項があります。詳細は、「Jython移行ガイド」を参照してください。

GraalPyを使用するには、ネイティブ・モジュールをLLVMでコンパイルして実行する必要がありますか。

いいえ。Python C拡張モジュールは、GraalPyで実行するためにソースからビルドする必要がありますが、pipを使用する場合、そのプロセスはほぼ自動的に行われ、システムの標準コンパイラが使用されます。GraalVMのツールおよびサンドボックス機能をPython C拡張モジュールに拡張するには、GraalVM LLVMランタイムを使用して実行できます。

GraalPyでGraalVMサンドボックス機能を使用できますか。

はい、できます。GraalPyには、graalpy-ltおよびgraalpy-managedという2つの特別なランチャが用意されています。前者では、C拡張ライブラリがネイティブ・システム・ライブラリを呼び出すことができますが、後者では、すべてのライブラリがビットコードとして使用可能である必要があります。これらのランチャで作成されたvenv環境では、pipを介してインストールされた場合、ネイティブ拡張の作成プロセス中にこのようなLLVMビットコードが透過的に生成されます。この方法でインストールされた拡張機能は、デバッグ、CPUおよびメモリーのサンプリング、およびサンドボックス化のためのGraalVMツールと連携します。埋込み担当者は、システム・アクセスを選択的に無効にしたり、C拡張子でもファイルシステムを仮想化したり、割り当てられるメモリーの量を制限したりできます。ネイティブ・ライブラリのコードを含むすべてのコードがJITコンパイルの対象となるため、その代償としてウォームアップやフットプリントが増加し、場合によってはピーク・パフォーマンスが低下します。

GraalVMのポリグロット機能はすべてGraalPyで動作しますか。

チームは、GraalVMのすべてのポリグロット機能が確実にPythonユーザーの期待どおりに動作することを目指して継続的な取組みを進めています。それでも、期待が明確でなかったり、複数の動作が考えられるケースが多々あります。チームはユース・ケースを積極的に検討し、最も便利で期待どおりの動作を提供するためにGraalPyを継続的に進化させています。

GraalPyにはどのようなパフォーマンスが期待できますか。

純粋なPythonコードの場合、ウォームアップ後のパフォーマンスは、CPython 3.10より約3-4倍高速(またはJythonより4-5倍高速)になると予想されます。デフォルト・モードで実行されるネイティブ拡張は、フル・ネイティブ・アクセスで、対応するCPythonと同じ速度で実行されます。LLVMビットコードとして実行されるネイティブ拡張がサンドボックス機能を利用する場合、GraalPyは通常低速で、CPythonのパフォーマンスの半分と予想されます。

JITコンパイラを使用する言語では起動に時間がかかると聞きました。それはGraalPyにも当てはまりますか。

状況によります。Pythonでネイティブ・イメージを使用する場合、またはgraalpyランチャを使用する場合、起動はCPythonと同等です。ネイティブ・イメージによって作成されたネイティブ実行可能ファイルを使用する場合も、JVM上で実行する場合も、ピーク・パフォーマンスに達するにはまずウォームアップが必要です。小規模なワークロードの場合、GraalPyは、コード・ループに到達してから数秒でCPythonのパフォーマンスを上回ることがよくあります。とは言え、実際の起動動作は実際のワークロードに大きく依存します。

複数のPythonコンテキスト間でウォームアップ・コードを共有できますか。

はい、これは正常に機能します。同じエンジンで複数のコンテキストを起動し、それらで同じコードまたは類似するコードを実行すると、コンパイルされたコードが複数のコンテキスト間で共有されるため、ますます高速になることがわかります。ただし、現時点では、この設定のピーク・パフォーマンスは単一コンテキストの場合よりも低くなります。