今回ベンチマークを行うアプリケーションはAmberです。

Amberは生体分子シミュレーション用アプリケーションです。（公式HP)

Amber は 有償のSolverと無償のツール群（AmberTools)に分かれており、
SolverのビルドにはAmberToolsのビルドも必要になります。
2020年2月17日時点での最新版は、Amber（Solver）がVersion 18 、
AmberTools が Version 19となります。

前回のHPLと同様に、Compiler、数値演算ライブラリ、MPIを変化させてベンチマークを取得していきたいと考えていたのですが…

今回は残念なお知らせからです。
AOCCを用いたAmbre18のビルドについては断念しました。

AOCCは、LLVMというCompiler基盤（ compiler infrastructure）で、C 言語と Fortran 言語は Clang、Flang というコマンド名にて実行されます。

Amber18 は、このClangとFlangを用いたビルドに対応していませんでした。
正確にいうと、clang と gfortran を用いたビルドには対応しているようですが、この通り実行すると、
C言語はAOCCで、Fortran言語は GCC を使うという、イレギュラーな対応となってしまいます。

更に、configrure 関連スクリプトの内部に、

#WARNING – PMEMD.MPI will likely not work with CLANG because it REQUIRES
# OpenMP support. It looks like there is an openmp version of
# clang but it all horribly confusing as to what version one
# needs etc – so for now we just leave as is. – Ross.

と、clangに関しても、安定動作について疑問がうかがえるコメントが見つかりました。
もしかしたらconfigureスクリプトやコンパイラオプション等に手を加えれば Amber18をビルドできるのかもしれませんが、
開発元がこのようなコメントを残している以上、
CLANGでの動作検証を試みたが安定できる状況に達しなかった、
という状況であると判断し、今回の検証では、AOCCを用いた検証は断念しました。

また、GCCとAOCLを用いたビルドにおいても、問題が発生しました。
ビルド時に以下のメッセージが発生してしまいました。

/usr/bin/ld: warning: libgfortran.so.3, needed by /opt/AMD/aocl/2.0/libs/libflame.so, may conflict with libgfortran.so.5

このメッセージは、OSに入っている libgfortran.so.3 と、今回インストールしたGCC 8.2.0 の libgfortran.so.5 との間で、競合が起きる可能性を示唆しています。
このメッセージ内容は、安定動作の観点から非常に好ましくない物と考えられますので、今回は GCC 8.2.0 と AOCLを組み合わせた場合の検証を断念しました。

では、GCC 8.2.0を使用した際に、どのような数値演算ライブラリを使用するかです。
AOCLは複数の機能を持つライブラリの集合体ですが、
その中でBLAS、LAPACKルーチンは、BLIS、libFlame というパッケージを使用しています。
GCC 8.2.0環境では、これらのパッケージをビルドし、作成されたライブラリを使用して検証を行うこととしました。

前置きが長くなってしまいましたが、ベンチマーク結果を報告します。
最初に、ベンチマークを行った環境は以下のようになります。

表１　ベンチマークハードウェア環境

表２　検証に使用した Amber18 環境

表３　Amber18 ビルドに使用したコンパイラ、MPI、数値演算ライブラリ

ベンチマークの結果の数値は以下のようになりました。結果は ns/day で、数値が大きい方がパフォーマンスが良いことを表します。
まず、同一インプットを使用した場合の、EPYC環境と Xeon環境の比較結果となります。

表４ 同一インプットを使用した際の AMD EPYC (ROME) と Intel Xeon ( CascadeLake )の比較　( ns / day )

次に、EPYC環境内での、開発環境を変更させた場合の結果の違いとなります。
表中の、ICは、” Intel Compiler “、IMPIは ” IntelMPI “、OMPIは ” OpenMPI ” 、Blis は “Locally Built Blis & Locally Built libFlame” の略となります。

表５　AMD EPYC環境における、開発環境によるAmber18のパフォーマンス比較 ( ns / day )

表４、表５から、以下の内容が読み取れます。

• AMD EPYC 7702 と Intel Xeon 8268 を比較した場合、同一並列数では後者の方が10~15%程度パフォーマンスが高い。1ノードでのピーク性能を比較した場合、前者の方が15%程度パフォーマンスが高い。
• AMD EPYC環境における開発環境について、最も高い性能を得られた組み合わせは、IntelCompiler + IntelMPI + MKL の組み合わせであった。

Amber18のベンチマークを行った感想ですが、EPYCがかなり善戦している印象です。
今回の結果では、Xeon環境でのAmber18実行時に ” MKL_CBWR ” の指定を行っていません。にもかかわらず、同一並列数の場合でも、Xeon環境に比べやや遅い、程度のパフォーマンスを見せています。
ノードあたりのピーク性能については、Xeon環境よりも高いパフォーマンスを示しましたが、今回の結果では、48並列から128並列の間での伸びがだいぶ鈍いため、あまり大きな差が得られませんでした。
この伸びの鈍さについては、インプット依存の可能性も考えられるため、１ノードあたりのピーク性能の差については、精査が必要かもしれません。

EPYCでの開発環境についてですが、HPLに続き、Amber18でも、IntelCompiler + IntelMPI + Intel MKL が最善という結論が得られました。
ただ、Amber18のビルドを実行していて、まだまだソースコードがEPYC環境向けに調整されていないという印象を強く受けましたので、現時点ではIntelCompiler以外についてはチューニングや整備が進んでいないためではないかと個人的には考えています。
近年のリリースの様子を見ていますと、AmberTools は毎年4月に更新がかかります。
その際にAMD EPYC環境向けのソースコードのチューニングが進んでいることを期待したいと思います。

次回はVASPのベンチマークを報告できればと思います。お楽しみに。