83. GRAPE-DR 上の LINPACK その2 (2010/5/30-6/1)

来週は ICS で Top 500 の数学がでるわけですが、例によって間に合わなかっ たのでリストにはでません。が、 11 月に 73 に書い たところからは開発が大きく進んではいます。

現在の数字は GRAPE-DR 366MHz 動作で 64 ノードでの HPL ベンチマーク性能 が 23.28 Tflops、効率 49% となっています。昨年5月の数字に比べるとノー ド数半分(カード数も半分)でほぼ同じ性能を実現できていて、実行効率がほぼ 2倍になっています。

電力あたり性能では大体 900Mflops/W というところで、微妙ですが QPACE よ り上にいけたかなあ？というところです。上にいってたらもうちょっとちゃん と発表します。

この性能向上は、HPL のコードを0から書き直すことで実現したものです。

既に 73 に書いたことの繰り返しですが、配布され ている HPL のコードでは、 GRAPE-DR、というよりもアクセラレータである程度 (アクセラレータ使わない場合の 5 倍程度以上)の性能向上を、あまり大きく ない主記憶で実現するのは極めて困難です。その理由は色々あるのですが、大 きなものは

1. 行列格納が列優先になっていて、行交換が本質的に遅い。
2. ノード間の行交換、放送のための、いわゆる縦方向の通信が、計算と 並行に動作しない。

もちろん、 HPL で列優先の行列格納をしていることには理由があり、それは ピボットサーチや、再帰分解ステージでのブロック幅が小さくなった時の処理 を速くするためです。行優先のままではこれらの処理がものすごく遅くなって しまい、実用的な速度にはなりません。

今回の我々の実装では、列幅が 16 程度になったところで行列を転置し、そこ から先は転置した、列優先で格納した行列を処理する、という方法でこの問題 を解決しました。転置は一般にはあまり速いオペレーションではありませんが、 行列の話がキャッシュラインの倍程度あり、また HugePage を使ってTLB ミス を避けるならメモリバンド幅の半分以上の速度はでます。 LU 分解ではいわゆ るアップデート処理、つまり大ブロックサイズでの行列乗算と、いわゆる再帰 的パネル分解、つまり、ブロックサイズが再帰的にどんどん小さくなるところ での行列乗算やピボットオペレーションの双方で複数回メモリ全体にアクセス するので、その殆どで連続アクセスででる性能に近い性能を実現することがア クセラレータを使った実装での鍵になります。転置を使うアルゴリズムは理論 上の最適解に近いものと我々は考えています。他に提案されている方法には、 例えばモートンオーダーやペアノ・ヒルベルト曲線のような空間充填曲線を使っ た順序で行列を格納することで縦横どちらでアクセスしてもある程度の速度は 出るようにする、といったものがありますが、この場合縦アクセスで、幅が小 さくなった時にはどうしても大きなオーバーヘッドが生まれます。我々の方法 では、転置オペレーション自体以外では常時オーバーヘッドなしで行列のアク セスができ、また転置でも主記憶のピーク程度の性能がでているので、これ以 上の性能向上は原理的に困難と考えています。

次に、縦方向の通信ですが、HPL ではかなり難しいことをやって縦方向のネッ トワークが1次元リングでも性能がでるようにして、そのかわり計算と並行にす るのは断念しているようにみえます。我々の現在の実装では、縦方向の通信を 単純な1行毎の交換と放送に戻し、その代わりに計算や横方向の通信と並行して 進めるようにしています。主記憶の負荷が増えるので、行列乗算自体の速度が 10% 程度低下するのですが、それでも縦方向の通信が完全に隠蔽できる効果は 非常に大きく、大きな性能向上が実現できました。

なお、ClearSpeed のドキュメントにもあり、また Tsubame でもやっているこ とですが、アクセラレータを使う場合には縦方向の通信と計算の順序を変える のが普通です。 通常 HPL では、縦方向の通信をブロックサイズ単位にして、ブロックサイズ での通信と、 DGEMM を交互に行います。しかし、アクセラレータを使う場合 にはこれでは DGEMM が細切れになって性能がでないので、行列全体を一度に 送ってから全体に対して DGEMM をするわけです。

しかし、この方法では縦方向の通信と計算を並行に行うことができません。 従って、我々は縦方向の通信を細切れにする方法に戻し、しかし、 そのことが DGEMM の性能低下につながらないように DGEMM の実装の変更を 行いました。細切れにしたら性能が落ちるのは、毎回縦に長い行列を送る必要 があるので通信が増えるからですが、もちろんこれは実は毎回同じ行列を送っ ているだけなので、前に送ったものを再利用すればこのような問題はありませ ん。何故 ClearSpeed の実装ではそうしていなかったのかわからないですが、 我々は再利用することで細切れにしても大きな行列を処理するのと同じ性能を 実現し、さらに通信とも並行動作させています。

これらの改良によって、かなり理論限界に近いところまで効率を上げることが できた、と我々は考えています。

今回それでは64ノードでの数字に留まっている上にエントリーもできていない のはどういうわけかというと、まあ、その、64ノードの数字がでたのが 5/28 だからというのは結果で、まず今回使ったノードはメモリを18 GB の増強でき た90台だけであること、もう一つは、カード2枚で HPL 性能を上げるのにまだ 成功できていないことです。

行列乗算自体は、1枚での漸近性能が 650Gflops 程度であるのに対して2枚では 1150 Gflops 程度とかなり良い数字を実現できています。しかし、残念ながら HPL の今回チューニングしたコードから使って速くするためにはまだ色々問題 があることが判明しました。

問題は非常に色々あるのですが、基本的はホスト計算機の主記憶バンド幅と I/O 性能に関係するものです。一つは、GRAPE-DR カード1枚だと DMA read と DMA write を並行して実行できし、性能もあがるのですが、2枚で read/write 並 列実行すると速度が上がらない上にホスト側でデータ化けが起こる、というも のです。これはしょうがないので read/write の並列実行は現在止めています。

もうひとつは、この、GRAPE-DR 側では DMA read/write 並列動作しない状態で も、2枚のカードの通信負荷がある状態だとノード間の IB による通信がブロッ クされてしまって、並行動作させない場合に比べても遅くなってしまう、とい うものです。これに関しては、回避する方法があるかどうかまだわかっていま せん。もちろん、現在の Core i7 920 + X58 + nF200 に比べて主記憶バンド幅 にもうちょっと余裕があるホスト計算機に交換するか、カード1枚で動かせるだ けのホストの台数を確保できればよいのですが、そんなお金はないので。

さらにもうひとつある問題は、上に述べたように行列乗算の漸近性能は上がっ ているのですが、DMA read によるホストから GRAPE-DR への転送については カード2枚にすることで殆ど速くなっていない、ということです。これは原因 も解決方法もわかっています。問題は、 DMA 転送の前に少し複雑なデータの 並べかえをホスト計算機で行っているのですが、これがカード1枚しかない時 には DMA 自体と並行して行うことで性能を上げることができたのに対して、 カード2枚になると上の IB での通信と同様に並行して動かすとかえって遅く なる、というものです。 CPU による主記憶アクセスが、特に 並べかえといった多少複雑な操作の場合にはメモリバンド幅を使いつくして しまうので、 DMA の優先順位がさがってしまうようです。

これを回避する方法は言うだけなら簡単で、ホスト計算機側で並べかえをして いるのをやめて GRAPE-DR、具体的にはこの辺の制御を行うFPGA の側でこの並 べかえをすれば済む話です。このようにして、ホスト側での回避可能な CPU に よる主記憶アクセスを可能な限り避けることで、原理的にはカード2枚である程 度の性能向上を実現することは可能であると考えています。

(以下 6/1 追記)

某巨大掲示板で、DMAR の代わりに PIOW を使えばどうか？というコメントがあ りました。ありがとうございます。これは実はすでにテストしていて、カード 2枚でDMAW と並行動作させるとやはりデータが化ける上に、 PIOW では PCIe のペイロードサイズが大きくならないのでスループットが大きく低下する、と いう問題があり、DMAR を使うほうがだいぶましです。

(6/1 追記終わり)

まあ、楽観的にいってカード2枚で効率35-40%、カード1枚での性能の1.4-1.6倍 程度で、196ノードまでメモリ増強できれば120Tflops(理論ピーク 294Tflopsで) というところです。

本当は少なくとも現在の1カードででている程度の性能が1年前くらいには実現 できていないといけなかったわけで、これは完全に私のプロジェクトマネジメ ントにおける失敗、つまりは十分な人的リソースをソフトウェア開発とチュー ニングに回すのが遅れた、ということによってます。

台数については、これもまあお金が一杯あればどうにでもなる話ですが、国立 天文台の中で置く場所をどうやって確保するかとか電気代をどうするかとかいっ た台内政治的な話もあり、解決の目処はついたところですがこれはこれで時間 がかかっています。

Previous

ToC

Next