クラウドHPCにおけるARMのソリューションコストの先行きは明るい

原文:Sunny Weather Forecast for ARM’s Cost of Solution in Cloud HPC Published 25/08/2020 By Branden Moore

クラウドHPCにおけるARMのソリューションコスト(NAG技術者ブログ記事)

クラウドコンピューティングの主要な推進要因の一つは、社内では容易に利用できないアーキテクチャやシステムへのアクセスです。。 その一例として、AWSが最近、独自にカスタム設計したGraviton 2プロセッサを導入したことが挙げられます。このプロセッサは、IntelやAMDのx86ベースのアーキテクチャではなく、ARMアーキテクチャをベースにしています。当社では、多くのクライアントから、ARMがHPCのニーズにどの程度適しているのかについて問い合わせを受けています。公開されているベンチマークはいくつかありますが、私は午後の時間を利用して自分で試してみることにしました。

このために、私は天気コードWRF v3.9.1.1をベンチマークすることにしました。 WRFv3には、異なる解像度(12kmと2.5kmの解像度)の2つの「伝統的な」 ベンチマークがあります。どちらのベンチマークも3時間のシミュレーションを行います。小さい方のベンチマーク(解像度12km)は一般的に数百コアまで、大きい方のベンチマーク(解像度2.5km)は数千コアまでスケールします。 しかし、今回のベンチマークでは、単一のノードで実行しました。また、今回のテストは自分の好奇心を満足させるためだけのものなので、統計的変動を捉えるために通常行うような複数回の再実行は行いませんでした。

私はベンチマークのハードウェアとして、Intel、AMD、ARMの各製品を比較してみたいと思っていました。 AWSは現在、大手クラウドプロバイダーの中で唯一、AWS Graviton 2プロセッサを搭載したARMベースのインスタンスを提供しています。 そのため、今回のベンチマークでは、AWS上のC5、C5a、C6gのインスタンスタイプにたどり着き、"フルノード "を得るために、利用可能な最大のインスタンスタイプを選択しました。ベンチマークに使用したシステムはすべて、OSとしてAmazon Linux 2を使用し、GCC 9.3.0をインストールし、WRFの依存関係[1]を構築するためにSpackを使用したので、ARM向けのビルドはIntelやAMD向けのビルドと比較して特に難しいという事はありませんでした。WRF自体をビルドする際に、デフォルトのコンパイル設定を変更したのは、GNU/Linuxの設定セクションに'aarch64'アーキテクチャを追加することと、ターゲットプラットフォームに最適化するためのチューニングパラメータ(-march=native -mtune=native)を指定する事だけでした。

table-arm-comparison

図1を見れば、このベンチマークは完全な比較ではないことは明らかです。C5(Intel)インスタンスはデュアルソケット構成ですが、C5a(AMD)とC6g(ARM)インスタンスはどちらもシングルソケットです。C5とC5aの両方にSMT(別名、ハイパースレッディング)がありますが、C6gにはありません。しかし、基盤となるCPU構成ではなく、各インスタンスが提供するパフォーマンスを比較することを検討すると、比較ははるかに簡単になります。

結果

SMT/ハイパースレッディング

多くのHPCアプリケーションは、SMTの使用中にパフォーマンスの低下を示します。そのため、多くのHPCセンターはそれを無効にします。 私は、このベンチマークがそれに当てはまるかどうか再確認したいと思いました。上記テーブルをざっと見てみると、今回のケースでは、WRFにIntelとAMDの両方のシステムでSMTを使用する(つまり、96スレッドをすべて使用する)ことでパフォーマンスの優位性があることがわかりますが、その差はわずかです。また、デュアルソケットのIntelシステムは、より大きなベンチマークでシングルソケットのAMDシステムを大幅に上回っていることがわかりますが、これはシステム全体のメモリ帯域幅が高いことが原因である可能性が高い[2]です。この記事の残りの部分では、「フルインスタンス」という言葉は、インスタンスに利用可能なすべてのvCPUを使用する事を意味します。

図1: SMTを使用した場合と使用しない場合の比較(短いほど良い)
fig1

WRFにおける、ARM、Intel、AMDにおけるパフォーマンスの比較

図2は、3つのアーキテクチャで両ベンチマークを実行した際の、WRFの総計算時間(起動時間やディスクへの結果の書き込みを含まない)を示しています。AWSのGraviton 2チップが非常に競争力のある性能を発揮していることがわかります。小規模ベンチマーク(解像度12km)では3つのベンチマークの中で最も遅いですが、大規模ベンチマーク(解像度2.5km)ではAMDを凌駕しています。また、Intelベースのシステムは、ARMとAMDの両方に比べて、他に類を見ないほどの性能の優位性を示しています。

図2: フルインスタンス(全てのvCPU)を使用した場合の計算時間(短いほど良い)
fig2

私は、Graviton 2プロセッサで利用可能なより高速なメモリ速度が、大規模ベンチマークでAMDシステムよりもパフォーマンスが優れている主な理由であると思っています。AWSがデュアルソケットAMD Romeインスタンスタイプを導入する場合、これはもちろん再検討する必要があります。Intelプロセッサのより高いクロック速度と2つのソケットを持つことによるメモリ帯域幅の増加により、パフォーマンスが大幅に向上しています。

WRFにおける、ARMとIntelとAMDのコストの比較

今回の調査は「クラウド」で行われるため、ベンチマークの際にはコストも考慮することが必要です。 AWSは、Graviton 2製品を非常に競争力のある価格で提供しています。 各インスタンスのベンチマークコスト(現在のところ、US-EAST-2リージョンでは、オンデマンド料金)は、Intelシステムが$4.08/時間、AMDシステムが$3.70/時間、そしてGraviton 2システムが$2.18/時間でした。

1時間あたりの価格に実行時間を掛けて、ソリューションのコストを算出します。 図3が示すように、IntelベースのインスタンスはARMベースのインスタンスよりもはるかに高いパフォーマンスを持っていますが、コストを考慮した場合、Graviton 2は(ソリューションに到達するまでにより長い時間がかかりますが)、より低いコスト対ソリューションを提供してくれます。

図3: コストの比較(安いほど良い)
fig3

これらのプラットフォームでのWRFのパフォーマンスとコストの間には、明確なトレードオフがあります。2.5kmベンチマークでは、理想的には、Intelベースのソリューションのパフォーマンスが、ARMベースのものより安価に実現できるポイントがあるかどうかを確認するために、スケーリング調査も行いたいところです。

図4: コストとパフォーマンスの比較(短いほど良い)
fig4

table-arm-comparison2

AMD EYPCやARM HPCのエコシステムが成熟するにつれ、これらのアーキテクチャをターゲットとしたコンパイラ(AMDのAOCCやARMのAllinea Studioなど)や他のLLVMベースのコンパイラによるパフォーマンスの向上が期待できます。過去には、Intel コンパイラが、gfortran よりも優れた仕事をしていることを見てきました。このベンチマーク研究を、追加のコンパイラで再検討してみるのも面白いかもしれません。

まとめ

本記事では、HPCにおけるARMプロセッサの適合性についての質問に答えて、人気のあるHPCベンチマークの一つであるWRFv3を3種類の「計算に最適化された」AWSインスタンス上で実行しました。AWSのARMベースのカスタム製品は、このベンチマークで利用できる最速のプロセッサではありませんが、非常にコスト効率の高いソリューションを提供しており、パフォーマンスは他のより伝統的なHPCプロセッサと比較しても遜色がないことがわかりました。

様々なHPCハードウェアソリューションの詳細なベンチマークやパフォーマンス分析にご興味のある方は、ぜひお問い合わせ下さい。

関連情報



[1] 私は最初にGCC 10を使用しようとしましたが、gfortran10とWRFはうまく機能していないようです。libgfortranのルーチンが原因で、WRFが実行時にクラッシュしました。
[2] AWSが他のクラウドプロバイダーで利用できるようなデュアルソケットAMD Romeインスタンスサイズを導入する場合、パフォーマンスプロファイルは大幅に変化するはずです。これは再検討する価値があります。
関連情報
MENU
Privacy Policy  /  Trademarks