SC14 - NVIDIAの示すExaScaleへの道

第3の改善候補は、レジスタファイルの階層化である。容量の大きく消費エネルギーの大きいメインのレジスタファイルを直接使うのではなく、小容量で消費エネルギーの小さいレジスタファイルをキャッシュとして付けて、レジスタファイルを階層化する。演算ユニットは、小容量のレジスタファイルを使うようにすれば、アクセス時間は短くなり、消費エネルギーも小さくできる。なお、この2つのレジスタファイル間のデータの入れ替えはコンパイラが管理する。

第4の改善候補は、回路設計によるSRAMの動作電圧の低減である。SRAMはGPUでも大量に使われているが、電源電圧を下げて消費電力を減らそうとするときに、最初に動かなくなるのがSRAMである。これを書き込みのアシスト回路を付け加えて、最低動作電圧を下げ、消費電力を減らすという案である。

第5の改善候補は、HBM(High Bandwidth Memory)を8枚3D積層し、プロセサチップと同じパッケージ基板に実装するという方法である。7nmプロセスを使えば、HBMは7～9pJ/bitとなり、信号の伝送もグランドを基準とする方式を使えば信号振幅を減らして0.54pJ/bitに減らせる。

なお、ここでは5つの改善案しか説明されていないが、後の評価では、グランドを基準とする信号伝送が6番目の改善案として加えられている。

この図ではコントラストが低くて読めないが、黄色の丸の中に書いてあるのは、左の箇条書きと同じで、上の丸にはSingle & Multi-Node Measureと書いてあり、時計方向に順にNode Level Cycle Accurate Simulation、Event Based Power Model、Application Analytical Modelsと書いてある。この4つを連携させて実ハードウェアの上でモデルの正しさを確認していく。

右の図はアプリケーションの振舞いを調べたグラフで、それぞれ8色の棒グラフがあるが、前述のDoEの6つのアプリケーションとTop500向きのLINPACKとGreen500向きのLINPACKに対応し、各グループは左から順に、GPUのIPC、GPUのWarpの収束、GPUのメモリバンド幅の利用率、GPUのDP演算の利用率、そして、CPUの利用率、ネットワークの使用率、Weak Scalingの効率を示している。

総じて言えるのは、LINPACKを除けば、CPUの利用率もGPUのDP演算の利用率も非常に低い点が目を惹く。

左の図は、K20xを使うTitanのような構成で、アーキテクチャや回路設計がシングルノードのエネルギー効率にどれだけ貢献するかというグラフで、6種のアプリケーションについて6つの改善案を順に適用して行ったときのGOps/Wの改善を示している。CNSとLuleshの改善は1.5～1.7で、その他は2.3～4.2倍という結果で、6倍という目標には距離があるという結果となっている。

右の図は、 20KノードのTitanのようなシステムと提案のExaScaleシステムを比較した改善率を示すグラフで、改善目標の25倍のところに赤線が引いてある。GFlops/Wでは、改善率は13倍から30倍であり、もう少し改善が必要というところである。一方、GOps/Wでは9倍から34倍とばらつきが大きい。

なお、左の図の1ノードのエネルギー効率の改善に比べて、右の図の改善率が大きくなっているのは、アシスト回路の追加によるSRAMの動作電圧の低減で、電源電圧を0.9Vから0.65Vに下げた影響や、システムのサイズが小さくなり信号伝送のエネルギーが減るなどの効果を組み入れたためではないかと思われる。

結論として、7nmへのシュリンクだけでは4倍程度の改善しか見込めず、アーキテクチャや回路の工夫がかつてないほど重要になっているという。

ここで挙げた改善案の適用で、LINPACKでの50GFlops/Wは実現できそうであるが、いくつかのアプリケーションでは、現状のコードでは25倍の改善という目標は達成できない。これらについてはアルゴリズムやソフトウェアを変更する必要がある。Exascaleへの到達を可能にする魔法の弾はないという結論である。