この質問は以前にも似たような質問があったことは知っていますが、私の質問はより具体的で、既存の質問は古いものです。そのため、状況は大きく変わっているかもしれません (たとえば、ベクトル命令について考えてみましょう)。
簡単に言うと、基本的に常に使用する必要のある Python モジュールがあり、Python コードは VM (タイプ 1 および 2) 上で非常に遅く実行されます (実行時間が 2 倍)。モジュール自体は主に C ライブラリのラッパー/API ですが、排他的ではありません。
Python 自体が影響を受けるのか、それともモジュールだけなのかを調べようとしています。Python は VM で実行すると大きな影響を受けることが分かっているのでしょうか?
答え1
あなたの質問からは、同じもの同士を比較しているかどうかを知る方法はありません。
適切に構成され、適度に負荷がかかった仮想化環境では、ほとんどの負荷はベアメタルよりも最大で数パーセント遅く実行されると予想されます。コードが非常にスケーラブルで、利用可能なすべてのハードウェア リソースを利用できる場合、特にリソースが不足している場合は、仮想化環境でのパフォーマンスが大幅に低下すると予想されます。コードが特定のアクセラレータ ハードウェアに依存している場合、仮想化の影響は実装によって異なります。
答え2
何も証明されていません。分離されていない変数が山ほどあります。Python のバージョン、オペレーティング システムのバージョン、ハードウェア リソース、VM リソースの割り当て、CPU モデルなどなど。
コード内のどの関数に時間がかかっているのかをプロファイルします。炎グラフ。Python ベースのスタック サンプリング実装は良いのですが、C 関数をどれだけうまくキャプチャできるかはわかりません。その場合は、C ライブラリと OS の可視性が向上するオペレーティング システム ベースのプロファイラー (eBPF、xperf) を試してみるとよいでしょう。
どの関数が遅いのかを詳しく調べます。その関数が何をするのかを把握し、可能であればソース コードを入手します。システム コールをカウントして、オペレーティング システムに何を要求しているかを測定します。
制限となるリソース（CPU、メモリ、ディスク、ネットワーク）を見つけます。パフォーマンス監視ツールを使用して、ホスト レベルでこれらのリソースを測定します。
異なる環境、ベアメタル、異なるタイプの VM、異なるハードウェアで結果を比較します。VM ホストのリソースをオーバーコミットしないでください。CPU や RAM は絶対にオーバーコミットしないでください。ベアメタル専用ホストと比較すると不公平です。
実際、これは、環境内での制限要因を発見するための一般的なパフォーマンス調査です。Python を使用すると、コード ランタイムが変更され、プロファイルと最適化が行われる可能性があります。
答え3
問題のコードが大量のコンテキスト スイッチングを実行している (および/またはハイパーバイザーが仮想コアを物理コアの周りに移動することでコンテキスト スイッチングを悪化させている) 可能性があります。コンテキスト スイッチングは、ハイパーバイザーではベア メタルよりも最大で約 100 倍高価になる可能性があります。ハイパーバイザーが仮想コアをさまざまな物理コアの周りにスケジュールするため、キャッシュ ミスも大きな要因になる可能性があります。
これらのオーバーヘッドの一部を軽減するには、仮想コアを物理コアに固定し、基盤となる CPU トポロジを VM (ソケット/コア/スレッド) に公開し、VM を完全に単一の NUMA ノード内に保持し、コードがキャッシュ/メモリのレイテンシに敏感な場合は、ホスト上にある CPU コア/スレッドの完全なセットをゲストに提供しないようにします。
ハイパーバイザーでのさまざまなワークロードのパフォーマンスは、ベアメタルの場合よりも大幅に低下する可能性があります。そこにある数字は何年も前のものですが、私はこれらのことをかなり定期的に再テストしており、過去 10 年間で状況はあまり変わっていません。