新たなベンチマークHPCG

Top500は、HPL(High Performance LINPACK)というプログラムの実行性能でスパコンをランキングしてきた。HPLは連立1次方程式を解くプログラムで、連立1次方程式の未知数の数は自由に選んで良い。

連立1次方程式を解く計算量は未知数の3乗に比例するのに対して、メモリの読み書きの回数は2乗に比例する。つまり、未知数を多くすると、演算量あたりのメモリアクセス回数が減り、高い性能を実現しやすい。このため、天河2号では996万個、京コンピュータでは1187万個の未知数の連立1次方程式を解いている。この計算には、天河2号は5.4時間かかり、京コンピュータでは29.5時間掛かっている。

しかし、HPL性能の測定のためには、各プロセサにどのように仕事を割り当てるかなどを調整し、高い性能が得られる条件を見つける必要がある。また、同じ条件で実行しても実行時間はある程度ばらつくので、何回か計算をやり直して、一番良い結果を登録するのが一般的である。このため、HPL性能の測定には、巨大スパコンを1週間から数週間使うことになる。

スパコンの寿命は、大体5年である。つまり260週間で、そのうちの1%くらいの時間をHPLの測定という実用的には役に立たない用途に使うことになる。しかも、その1%は最も価値の高い旬の期間なので、かなり勿体無い。このため、 Blue Watersスパコンは、HPLの測定は時間の無駄ということで、Top500には参加していない。

連立1次方程式は、多くの科学技術計算に出てくる。このため、LINPACKが高速で実行できることは科学技術計算が高速で実行できることと強い相関があったのであるが、1000万元という巨大な連立1次方程式で、すべての係数が非ゼロというような問題は、まず、無い。

物理現象をシミュレーションで解く場合、隣接する格子点からは影響を受けその部分の係数は非ゼロとなるが、隣接していない格子点からは直接影響が無くその部分の係数はゼロである。したがって、大規模な問題では、大部分の係数はゼロで、非ゼロの係数はわずかという疎な係数行列になるのが一般的である。つまり、LINPACKが解いている問題と現実の問題とは性質が異なり、LINPACK性能が高いことが実アプリの実行性能が高いことにあまり繋がらなくなってしまっている。

そうなると、高いLINPACK性能を達成してTop500の1位を取ろうという努力は、実用的には意味の無い努力で、Top500の存在はスパコンの発展にプラスになるどころか、間違った方向にスパコンの開発を引きずってしまうマイナス要因になってしまう。

このような懸念から、テネシー大のJack Dongarra教授らはHPCG(High Performance Conjugate Gradient)というベンチマークプログラムを開発している。なお、Jack Dongarra教授は、Top500の主催者の1人で、HPLを開発し人物である。

HPCGも連立1次方程式を解くのであるが、 格子点間の影響が強いまとまりであるローカルドメインが多数存在するというモデルで、ローカルドメイン内の格子点間の影響を表す係数は非ゼロが多いが、異なるローカルドメインに属する格子点間の影響を表す係数はほとんどがゼロになる。つまり、係数行列の大部分の要素はゼロとなるという問題を解く。

HPCGでは影響が強い格子点のグループであるローカルドメインが多数存在するモデルで、係数行列の1行の非ゼロの係数は3次元の隣接関係にある27個

そして、係数行列の1行の非ゼロの値は3×3×3の隣接した格子点間の係数に相当する27個だけである。未知数の数は1000万を超える式で27個しか非ゼロの係数がないというような問題を解くわけである。

このような問題をLINPACKと同じ方法で解くことは不可能ではないが、効率が悪い。一方、Conjugate Gradient法は、未知数の近似値から誤差を計算し、誤差から未知数の近似値を補正するという反復収束法で、ゼロの係数が多い場合は計算量が少ない解法である。

しかし、係数値が非ゼロの場合しか演算を行わないし、未知数メモリのアクセスは飛び飛びで、演算数は少なく、メモリアクセスのオーバヘッドは大きい計算であるので、GFlops値は伸びない。

横軸がノード数、縦軸がGFlopsのグラフで、青がピーク演算性能、赤がHPL(High Performance LINPACK)、緑がHPCGのGFlops値

この図に示すように、32ノードのシステムのピーク演算性能は5000GFlops弱で、HPLでは4000GFlops強とピークの80%以上の性能が出ているが、HPCGの場合は、0.5%程度の性能しか出ていない。つまり、HPCGでは演算時間よりも、飛び飛びのメモリアクセスやノード間のMPI通信の時間が性能に大きく影響している。このため、HPLで性能が高いシステムがHPCGでも性能が高いとは限らない。

また、HPCGで高性能を出すための技術の開発も必要となる。

京コンピュータ8ノードの結果。オリジナルのHPCGコードでは130秒掛かった計算がチューニングすると1/10になった

理研AICSの丸山氏が、オリジナルのHPCGコードに対して、出来るだけメモリアクセスが連続になるようなチューニングを行った結果、性能が10倍になったという。ただし、8ノードでの結果であるので、MPI通信の影響は少なく、大規模なシステムではバランスが変わってくる可能性がある。

HPCGの第1版のプログラムはリリースされたのであるが、まだ、HPCGは未熟であり、実アプリ、実マシンでの確認を行う必要がある。また、コードも必要に応じて変更していく必要があるという状況だという。

HPCG実用化の次のステップ

Dongarra教授らのHPCGの開発グループはHPLの使用を止めてHPCGに置き換えることを提案しているものではない。36年間使ってきたLINPACKの歴史的重要性やLINPACKによるTop500のブランドは捨ててしまうにはあまりに重要であるという。そして、HPCGは、Top500においてHPLと並ぶ性能尺度として使われるというスキームを示した。