SC18 - スパコンまるでわからんBoF(2) 「スパコンまるでわからん」 - HPCxベンチマークで何を測定すべきか

牧野先生は、HPCxベンチマークで何を測定すべきかについて述べた。

過去40年に作られたHPC用のベンチマーク

過去40年にHPCのベンチマークとして、次の一覧に示すようなものが作られた。

しかし、現在、広く用いられているのはHPL(並列LINPACK)だけであり、その他(2013年のHPCG、2014年のHPGMGは除くと思われる)は消えていった。なぜHPLが生き残ったのか？

牧野先生の意見では、HPLは他のベンチマークが持っていないユニークな性質を持っているという。それは、

解くべき問題だけが決められており、解き方やプログラムは規定されなかった(その後、計算量が少なくなる解法が発明され、それを使ってはいけないという規定が追加されているが、計算量を減らさなければ、他の解法を使ってもよい)
問題のサイズが規定されていない。K FlopsでもYotta Flopsのマシンでも測定できる。

そのため、マシンの構成や規模が変わっても意味のある測定ができるベンチマークになっている。

なぜHPLは生き残ったのか？問題だけが決められ、それを解くソースコードやアルゴリズムは規定されていない。制約は、演算量を減らす解法は禁止という条件だけで自由度が高い

HPLでは、マルチプロセサ間の通信量はあまり多くなく、メインメモリのサイズを大きくすると通信量を減らすことができる。さらにキャッシュサイズを増やすとBF比(メモリバンド幅と演算性能の比)も小さくすることができる。

そして、一般的なマルチコアマシンの場合はDGEMMカーネルだけを最適化すれば性能を高めることができる。

端的に言うと、HPLはスパコンのアーキテクチャの数十年にわたる変化に適合することができたので、生き残ったのである。

HPLはスパコンのアーキテクチャの数十年にわたる変化に適合することができたので、生き残った

生き残ったからHPLで良いというわけには行かない。だから、新しいベンチマークを作ろうとしているわけであるが、

HPLは実アプリケーションの性能を代表していない
固定したアプリケーションの集合では長期にわたって生き残れない
固定した解法アルゴリズムの集合では生き残れない

ことは分かっているので、この問題を解決する必要がある。その方法としては、HPLに加えてHPCxという新しいベンチマークを加えるというアプローチが良さそうである。

HPLは浮動小数点演算性能を測定しているので、それを補完するHPCxはキャッシュやメモリのバンド幅、通信バンド幅などを測定するようにしたい。HPLの測定値をf、HPCxの測定値をxと呼ぶと、x/fが大きくなるようにしたい(x≈fであれば、わざわざxを測定する意味がない)。しかし、牧野先生は、多くの問題ではx/fを大きくしようとするとエネルギー効率が低下するという。そして、x/fの最適値は問題によって変わるだけでなく、1つの問題でもアルゴリズムや実装によって変わってしまう。このため、多くの研究者はx/fとして必要な値を小さくすることに努力しているという。

HPLは浮動小数点演算性能を測定するので、HPCxはそれを補完する性能を測定したい。しかし、HPCxの測定値xを大きくするとエネルギー効率は低下するので、現代の研究とは逆方向

また、最近の幅広のSIMDや複数レベルのキャッシュを持つ複雑なプロセサの場合、本当のアプリケーションの性能ボトルネックはいろいろなところで発生するが、ベンチマークプログラムでは、これらを再現するのは難しい。

京コンピュータやポスト京の経験では、メモリバンド幅や浮動小数点演算性能以外の要因が性能の制約になるアプリケーションが多かったという。

最近の幅広のSIMDや複数レベルのキャッシュを持つ複雑なプロセサの場合、本当のアプリケーションの性能ボトルネックはいろいろなところで発生する。ベンチマークでこのような問題を再現するのは困難

牧野先生の考えをまとめると、次のようになる。

ベンチマークは、どのようにハードウェアを設計すべきかの指針を示すものであるべきである
HPLは長寿のベンチマークを作る方法を教えてくれた
原理的には、長寿命のHPCxを作ることは可能である
しかし、深いメモリ階層を持つ現代のマルチコアプロセサでは、多くのアプリケーションの性能はHPCxで測定されるもので制約されるとは限らない
多分、アプリケーションベンチマークの新しい作り方を考えだす必要があると思われる。そのやり方は、ソースコードやアルゴリズムを規定するのではなく、問題を規定するような広範な最適化を許すという形であろう