Previous ToC Next

136. ShenWei TaihuLight その2 (2017/4/15)

133 で TaihuLight のことを書きました。去年の12月に、ちょっと使わせてみていただけないでしょうかみたいなメイルを書いて送ってみたら返事がきてどぞとのことだったので、FDPS と Formura をなにか、というのを AICS の粒子系チームとして少しやってみていました。この時期だと全系実行もまあ性能によってはできるので。

達成できた性能についてはまだ秘密なのですが、以下ちょっと思うことを。

アーキテクチャは、1グループが1コアのマネジメントコア (MPE) と 64個の演算用コア(CPE) で、どちらも 256bit SIMD の FMA 演算器が1つ、 1.45MHz 動作でこれが4グループあり、1チップの名目ピーク性能が3016Gflops です。一応4グループで共有メモリですが、基本的にこれは1グループ1MPIプロセスで使うことが想定されているようです。

正直なところちゃんと動かすのはとてつもなく大変でした。(大変だったのは私ではなくてチームの皆様です。お疲れさまでした)理由はいくつかあるのですが、一つはコンパイラの最適化が結構××で、それなりに無駄はない命令列をだしますがスケジューリングは全然で、おそらくコアのほうはインオーダーなので基本的にアセンブラで書かないと全然性能がでないこと、もう一つは、MPE が恐ろしく貧弱で、基本的になにもかも CPE にもっていかないと性能がでないこと、さらにもうひとつは、ハードウェア・ソフトウェアの信頼性が今三つくらいで、特に大ノード数でそもそも動かないとか通信が謎な性能ゆらぎ(というか、、、グローバル通信が秒単位で終わらないとか、、、)があること、さらにドキュメントが(少なくとも我々が入手できたものは)中国語でも限られていて特に命令セットのドキュメントがなかったこと、といった辺りになります。

OpenACC とか一応あるのですが、あんまりそういうのは信用しないでathread ライブラリというのを使いました。これだと athread_spawn でCPEの演算カーネルを起動できます。CPE からは、 athread_get、 athred_put というライブラリ関数で DMA を起動してメインメモリを読み書きできます。DMAでなくて load/store もできるようですが、遅いので使えません。遅いといえば athread_get/put も起動オーバーヘッドは結構あるので、それを減らすには低レベルの関数を使うと変更の必要がないパラメータ設定をスキップとかできるのでかなり速くなります。これはドキュメントは存在していなくて使ってる人に聞くとそういう答が返ってきました。CPE 間の通信はマクロがあってそれを使えばいいという説明を聞いたのですが、なんかそれでは駄目でインラインアセンブラを使ってました。これは、FIFOキューがあって、書いたものが10サイクルくらいあとには読めるというものでした。通信できるのは 8x8 のアレイの縦と横で、斜めは直接にはできません。但し、縦、横には放送もあります。これはいかにも行列乗算には便利そうな機能ですが、粒子間相互作用の計算にも悪くはありません。

FDPS を動かすことを考えたわけですが、とにかく MPE がとてつもなく遅い、というのは始めからわかっていたので、相互作用計算以外の部分、つまり、領域分割の生成、粒子のノード間の移動、ツリー構築(粒子のソートや、ソートした粒子からのポインタの生成、ツリーセルのモーメントの計算)、相互作用計算のために他のノードに渡す情報の生成、相互作用リストの生成、時間積分、といったことを、基本的に全てCPE でやる必要があります。ところがCPE側ではDMAを使わないとメインメモリとの転送が速くならないので、書くのはそれなりに面倒です。とはいえ、今回、実際にソート、モーメント計算、時間積分といった、相互作用計算以外のほとんどのところをCPEで実装しました。

問題は、それでもまだ速度が足りない、と予想されたことです。これは、メインメモリのバンド幅が極端に小さいので、CPEにもっていってもまだ性能が不足するからです。従って、今回、ツリー構築、相互作用リストの生成は複数ステップに1度にする、という、重力多体系ではこれまであまり使われたことがない(分子動力学計算では一般的ですが)方法を FDPS に実装しました。

相互作用カーネルは似鳥君が秘術をつくして書いたもので、かなり理論限界に近い速度がでています。が、まだ、その、アプリケーション全体としての数値は、、、というところです。これはアーキテクチャの限界というより時間切れで、論文投稿の〆切までにできたことは、、、というような感じでした。

実際に実現できた性能とかソフトウェアの状況とかハードウェアの信頼性とかいろいろ問題はあるのですが、しかし、おそらく最新ではない半導体プロセスを使って Green500 の上のほうに入り、4万チップとそれほど巨大ではない構成で Top1 をとる、非常に無駄の少ない設計であることを考えると驚異的なシステムというべきではないでしょうか。

時間切れで性能が十分にはでてないのであまり偉そうなことは言えないですが、チューニングも(ドキュメントやコンパイラが××だったこと以外は、、、これは本当に最悪でしたが)比較的方針がたてやすく、予測可能な性能がでるという意味では好ましいものでした。

アルゴリズムの根本的な変更(も今回結構行いましたが)以外では、チューニングの方向は

  1. CPE に載せる
  2. メモリアクセス量を減らす

ということで、CPE の演算性能は計算コードのほとんどの部分では圧倒的にあまるので、アセンブラで書くといったチューニングは本当に演算量が多いカーネルだけで十分です。

作業量については、特に athread+DMA で書くと多いわけで、少し違う書き方を考えるとか(もちろんそれがOpenACCなはずですが)色々な検討の余地はあると思いますが、DMA で明示的にメモリアクセスをすることで、メモリアクセスの量を必要最小限にし、高い性能をだすことが可能になります。また、キャッシュベースのメニーコアではどうしても問題になるコア間通信や同期が、通信用のハードウェアによって極めて高速に行えるのは大きなメリットで、非常に細粒度な並列処理を行うことができます。このため、64コアあってもそれほど多いわけではなく、実際にアプリケーションをまともに動かすことが可能になっています。放送ができること、ハードウェアサポートはないにしてもソフトウェアで非常に高速に縮約ができることは大きなメリットで、かなりベクトルプロセッサ的な使いかたができます。要するに、プログラミングモデルとしては、そこそこの大きさの主記憶とベクトルレジスタがあるベクトル機に巨大な、だけれども低速な拡張メモリがある、Cray や日本の第一世代のベクトルプロセッサで拡張メモリ側にデータを置くのと同じような話になるわけです。

まあその、ベクトルプロセッサ的に使うなら SIMD でいいではないかと私は思うわけですが、そこはそれ、、、

PEZY-SC では階層的でコヒーレンシのないキャッシュでコア数の限界を克服しようとしているわけですが、SW26010 ではローカルメモリとDMA でコア数の限界を克服しようとしたわけです。どちらも成功している、といえると思います。
Previous ToC Next