Google Compute Engine での MPI レイテンシ

Google は、Google Compute Engine (GCE) サービスへのアクセスを一般に公開することで、IaaS クラウド コンピューティングの輪に正式に挑戦を開始しました。 Google が宣伝する差別化機能の XNUMX つは、 パフォーマンス ネットワークインフラストラクチャの。
私たちは、HPC アプリケーション ドメインのコンテキスト内で相互接続のパフォーマンスがどのようなものかを確認するために、このサービスを簡単に試してみることにしました。 特に、MPI クラスター内の XNUMX 台のマシン間の遅延を測定することに興味がありました。
このテストでは、XNUMX つのインスタンスをスピンアップし、OpenMPI クラスターをセットアップしてから、osu_latency ベンチマークを実行しました。 OSU マイクロベンチマーク テスト スイートを使用して、ピンポン方式でノード間で 0 バイトのメッセージを送信するのにかかる時間を測定します。 以下に報告される数値は、3 回の試行で平均された一方向の潜時数値です。 試験ごとに新しいマシンのペアが起動されました。

*すべての遅延数値はマイクロ秒単位で測定されます
報告されたレイテンシの数値は、テストしたすべてのインスタンス タイプでほぼ同じです。 テスト間の差異は、マシン上の他のテナントからの競合が原因である可能性があります。 クラウド コンピューティング インスタンスのベンチマークは、非常に難しい問題として知られています。 将来的には、より多くのインスタンスおよび異なる期間にわたって、より徹底的なテストを実行することを検討します。
比較のポイントとして、Amazon EC70 インスタンスで同じテストを実行すると、レイテンシは 90 ～ 2 マイクロ秒であることがわかります。 これは真の同一比較ではないことを指摘することが重要です。Amazon は、特別なクラスター コンピューティング インスタンス タイプと配置グループを提供しています。 後者により、帯域幅が向上し、同じグループ内のマシン間の待ち時間が短縮されます。 GCE レイテンシーの数値は Edward Walker の数値に近いようです。 報告 EC2 上の非クラスター コンピューティング インスタンスの場合。 おそらく Google は、今のところ Web サービスのホスティングというより一般的なワークロードに焦点を当てており、最終的には HPC などの他のドメイン向けにインフラストラクチャを調整することに重点を置くようです。 現時点では、GCE は本質的に「恥ずかしいほど並列」なワークロードに適しているようです。
このような種類のマイクロ ベンチマークは、実際のアプリケーションを実行したときに見られるパフォーマンスを必ずしも表しているわけではないことに注意してください。 期待されるパフォーマンスを正確に把握するために、マクロレベルのアプリケーション固有のテストを実行することをお勧めします。 レイテンシのペナルティを軽減するには、いくつかの方法があります。

• 特定のクラスのシミュレーション問題では、モデルを別々の部分に分解し、それらを並行して評価できる場合があります。 パブリック クラウドの出現により、考え方の転換が必要です。 単一のオンプレミス クラスターを使用するのではなく、分解された部分を同時に操作できる多数の小さなクラスターを起動することができます。
• 可能な場合は、ハイブリッド Open MP / MPI アプリケーションを活用します。 クラスターノード間のチャットの量を減らすことは、遅延コストを完全に回避するための優れたアプローチです。

私たちは、さまざまなクラウド プロバイダーの間で軍拡競争が続くことを楽しみにしており、HPC のパフォーマンスが向上し続けることを期待しています。 一例として、Microsoft は最近新しい機能を発表しました。 Azure 向けの HPC オファリング これにより、インスタンス間の Infiniband 接続が保証されます。 ほとんどの場合と同様、大規模なクラウド コンピューティング プロバイダー間の競争はエンド カスタマーにとって非常に有益です。 Rescale では、お客様に可能な限り最高のパフォーマンスを提供し続ける機会に興奮しています。