Hot Chips 22 - 日米10PFlops級スパコンのインターコネクトの詳細が判明

8月22日から24日にかけてスタンフォード大学で開催されたHot Chips 22では、インターコネクトというセッションが設けられ、日本の「京」スパコンと米国のBlue Watersスパコンのインターコネクトの発表が行われた。

実はHot Chipsの姉妹コンファレンスとしてHot Interconnectsという学会があり、同じスタンフォード大学で、前の週の8月18、19日の両日開催されている。インターコネクトはこちらでカバーする領域ではないかとも思うが、両スパコンのCPUである富士通の「SPARC64 VIIIfx」とIBMの「POWER7」が昨年のHot Chips 21で発表されているので、それに続いてインターコネクト用のLSIチップの発表をやろうということでHot Chips側でもセッションを設けることになったものと思われる。

富士通のICC

富士通が「Tofu」と呼ぶインターコネクトに関しては2009年11月のIEEE Computerに論文が発表されているが、このときの発表はインターコネクト全体のアーキテクチャ的な話で、ハードウェア実装については触れられていなかった。

以下の図の中の上側中央の図で球で表されているのがSPARC64 VIIIfxプロセサとメモリからなる計算ノード(ノードと略す)で、この計算ノード12個のグループをTofuユニットと呼ぶ。Tofuユニットの中では、この図に示すように4ノードのリングが3層に存在し、中央のリングの各ノードは上下のリングの対応するノードから繋がり、上下のリングの対応するノードは相互に繋がっている。

そして図の右側の3DTorusと書かれている絵のように、Tofuユニットが3Dトーラス構造で接続されている。パイプで表現されたTofuユニット間の接続はTofuユニット内の対応するノード間の12本の接続が含まれている。Tofuユニット内の接続は縦、横は2個のノードで高さ方向には3個のノードがあり、縦、横はメッシュ接続で、高さ方向は戻りのあるトーラス構造になっている。そしてTofuユニット間は3Dトーラス接続であるので、全体では6Dのメッシュ/トーラスという表現になっている。

CrayのXTスパコンのような単純な3Dトーラス構造としなかったのは、ノードが故障してもTofuユニットの中のパスを使って故障ノードを迂回して、アプリケーションから見える3Dトーラスビューを維持できるという耐故障性を実現するためである。

ここまでは昨年の論文で明らかになっていたのであるが、今回は、図の下側のCPUに接続されてインターコネクトを形成するICCと呼ぶLSIについての発表が行われた。ICCは、この図のように、Tofuユニット内の他のノードと接続する4本のリンクと3Dトーラスを構成する6本のリンクを持っている。そしてCPU側には4台のコミュニケーションエンジンを持ち、これらの14個のポート間のデータ転送を行うルータエンジンを持っている。

ICCは富士通の65nmのCMOSプロセスで作られる18.2mm×18.1mmのチップである。クロックは312.5MHzで、一部は倍速の625MHzを使っているが、全体としてクロックが遅いため、CPUより1世代古いプロセスを使ったものと思われる。また、「京」スパコンでは一時に大量のチップを製造する必要があるので、製造キャパシティの小さい富士通のFabで先端の45nmプロセスに製造を集中させないという考慮もあるのかもしれない。そして、ノード間を接続するICCリンクのバンド幅は5GB/s×2(出入りで別の伝送路を持つ)であり、物理的には6.25Gbpsの伝送路を8本束ねたものを2組使用している。

ICCとCPUの間はバスブリッジを通して20GB/s双方向で接続されている。ICCは破線より上側のノードドメインと、下側のルータドメインに分かれており、ICCを通過するパケットトラフィックに関してはルータドメインだけで処理を行い、ノードドメインが関係するのはCPUからのデータの送受を行う場合だけである。

TofuはRemote DMA(RDMA)機能を持っており、最大16MBのデータを1つのコマンドで転送する。ただし、16MBをひと塊で送るのではなく、インターコネクト上では最大1920バイトのパケットに分割して送受信される。

通常のRDMAではCPUがICCにRDMAコマンドを送ると、ICCがDMAでCPU側のメモリを読んで宛先に送るが、短いメッセージの場合には効率が悪い。このため、短いメッセージの場合は、コマンドとデータまとめてCPUからICCに送ってしまうPiggybackという手法を使っている。これにより通信レイテンシが2/3程度に短くなっている。発表されたグラフは相対値であったがグラフの隠された予稿集の図を見比べると、Piggybackを行った場合の短メッセージ転送のレイテンシは1μs程度と思われる。そして、1920バイトのメッセージの場合のレーテンシは2.5μs程度となっている。

メッシュやトーラスなどのネットワークでは隣接ノード以外のノードへのメッセージは中間のノードを経由して転送されて行く必要がある。ノード0が隣接したノード1にデータを送り、ノード1が隣接したノード2にデータを送る場合を考えると、ノード1が公平にノード0からのデータと自ノードのプロセサからのデータに半々のバンド幅を与えるとすると、ノード1からノード2へのリンクにはプロセサ0とプロセサ1のデータが半々に乗ることになる。しかし、ノード2がノード1からのデータとプロセサ2からのデータに半々にバンド幅を割り当てると、ノード2からの出力としては、プロセサ0、1は25%のバンド幅で、プロセサ2が50%のバンド幅を使ってしまうという不公平が生じる。

この問題に関してTofuではギャップを入れることによって不公平の発生を抑えるという方法をとっている。この図の例ではノード0は2つのギャップ、ノード1は1つのギャップを入れることで各プロセサが1/3ずつのバンド幅が使えるという図になっている。

会場で示されたスループット性能の図では、右側の3ノードのグラフでは、ギャップが0の場合はノード0、1が各25%、ノード2が50%のバンド幅であるのに対してギャップを16にするとそれぞれ1/3程度のバンド幅を使うようになる。

しかし16よりもギャップを増やしてしまうと全プロセサともに使用できるバンド幅が減少してしまう。このように、3ノードの場合でもギャップ値の選択は容易ではないのに、実際のシステムでは接続は6次元になり通信パターンや混雑の状況は色々と変わるので、ギャップの挿入量はユーザが指定できるのでご勝手にと言われてもユーザは困ると思われるが通信の上位層で公平性を確保する機能があるのであろうか。