156. 富岳から学ぶべきこととポスト富岳 (2022/4/20)

年度も変わって、牧野の旧理研AICS、現R-CCS での「粒子系シミュレータ研究チーム」も10年の年限ということで解散になりました。富岳開発のFS2020プロジェクト自体は前年度、2020年度で終了しており、プロジェクトリーダーの石川さんは既に2020年度末に R-CCS を離れています。

AICS を R-CCS に名称・組織変更し、機構長/副機構長も全て入れ換えた理事長は昨年度末で交代となり、理事も大きく入れ替わったようで、名称変更はプラスだったのか？という気はします。名称・組織変更(及び各センターのトップの入れ換え)は前理事長が進めたもので、AICS だけでなく基本的に全センターが対象になりました。新理事長がこれから理研をどういう方向にもっていくのかは注目されます。

一方、ポスト富岳は今年度にフィージビリティスタディの予算がついており、今年度と来年度で形を決める必要があるものと思われます。牧野は HPCI 推進委員会とかその下のワーキンググループとかに関わってないので、外野の立場+富岳成果創出加速プログラムで使う側として、ポスト富岳がどうあるべきかをここで述べておこうと思います。

まず、使う側から見ると、富岳は正直なところ非常に手強いです。要するに性能がでません。その理由はほぼ 153 に書いた通りで、

• 演算器、1次キャッシュ、2次キャッシュのレイテンシが非常に大きい。 Skylake Xeon の 2-3倍ある。
• それにも関わらず Out-of-Order 実行の資源は半分程度しかない。
• それにも関わらず浮動小数点演算のアーキテクチャレジスタは32しかない。
• さらに、1次キャッシュ、2次キャッシュのバンド幅も Skylake Xeon の 半分程度である

そうすると、以下のような疑問が発生します。

1. 何故そのような大レイテンシ・小バンド幅・小OoO資源の実装になったのか?
2. どこか増やすことで改善できなかったのか？
3. もっと別のアプローチはなかったのか？

「京」でクロック 2GHz、はレイテンシが6で、 Skylake に比べて悪いとはいえそこまで悪くなく、 A64fx ほど極端な設計ではなかったと考えられます。また、非常に大きな違いとして「京」ではアーキテクチャレジスタが128あって、コンパイラによる最適化の余地が十分にあった、ということがあります。これは、富士通で「京」の開発を率いた井上愛一郎さんの判断が良かった、ということもできますし、その前の世代の SPARC64V で発覚したレジスタ不足問題への自明な対応であったともいえます。何故問題が起こるとわかりきっているアーキテクチャレジスタ32本+大レイテンシ演算器という設計を選択したのかは牧野にはよく理解できていません。

単に電力性能をあげるだけならクロックを落とすほうがよい気もしますが、コアロジックがダイエリアに占める割合がそんなに大きくないことを考慮すると、多少の面積増加でクロックをあげることができると面積あたりの性能を大きくあげることができ、コスト削減に大きく貢献している可能性が高いです。しかし、繰り返しになりますが、これは、少ない OoO資源と組み合わさって、演算リッチなカーネルでも性能をだすことを非常に困難なものにする選択でした。

1次キャッシュ、2次キャッシュのバンド幅も同様で、消費電力に大きなインパクトがあります。512ビット幅 SIMD、2way の浮動小数点演算ユニット、 N7プロセスで HPL 15GF/W という汎用プロセッサとしては驚異的な電力性能を実現するためには、バンド幅を落とすことが重要であることは間違いありません。A64fx の1つのプロセッサコアは 3mm x 1.5mm 程度あり、チップ全体は概ね20mm角で、L2キャッシュからプロセッサコアまでは最大で 10mm 近くと非常に遠くなっています。電気信号なんだから光の速さで伝わるんじゃないか？と思うわけですが、LSI上の配線はそうではありません。これは、いわゆるRC遅延が非常に大きくなるからです。分布定数回路でも、遅延時間はRC/2 (R, C はそれぞれ配線全体の抵抗と容量)で近似できることが知られています。このため、同じ長さで配線を幅、高さ、グラウンドからの距離全て半分にすると、容量は同じ、抵抗が4倍になって遅延時間が 2倍になります。消費電力は同じです。

それでは話にならないのでパイプラインレジスタやリピータを多数いれることになるわけです。そうすると、配線だけでなくそれらのリピータやレジスタも電力を消費します。このため、同じ長さの配線の消費電力は微細化するほど増えることになります。(駆動電圧が下がればその分は下がります)

2次キャッシュまでの距離が長いのは富士通が SPARC64 VI 以来継続してきた共有 2次キャッシュアーキテクチャだからで、総コア数の1/4である12コアが2次キャッシュを共有するため必然的に距離が長くなるわけです。長い配線に対して電力を抑えるためには遅延時間を長くし、また本数を減らすしかなく、そのため 40サイクルという一昔前なら主記憶ではないかと思うような遅延時間と B/F=1 というこれも主記憶ではないかと思うようなバンド幅で、しかし8MBとそれぞれサイクル毎に32演算する、さらにレイテンシも巨大な12コアで共有するにはあまりに小さなキャッシュになっています。

2については、OoO 資源を大きくふやさない、レイテンシも改善しないとして例えば演算器・1次キャッシュのレイテンシについては以下のような対応が可能だったと考えられます。

• アーキテクチャレジスタを増やす
• マルチスレッドにする
• SIMD 幅を増やし、演算器を1セットにする

また、少ないアーキテクチャレジスタでも、「十分なOoO資源があれば」十分先までの命令をデコードして実行キューにいれること演算パイプラインを埋めることができる、というのは本当ですが、その時に必要なOoO資源の量、具体的には命令ウィンドウサイズや物理レジスタの数は、アーキテクチャレジスタが「十分」にあればアンロールだけで埋められる、という時の「十分」と同じではありません。これは、OoO でパイプラインを埋めるには単純に考えるとレイテンシ分だけ最内側カーネルを完全にデコードし、全ての演算に物理レジスタを割り当てることになるのに対して、アーキテクチャレジスタが十分にあってアンロールできれば命令ウィンドウは遠くまで見る必要はないし、アーキテクチャレジスタもループ内で使い回しができるからです。

3 については、根本的な問題は

• 広いSIMD幅をもつ物理的に大きな演算コア
• 多数のコアをまとめる物理共有キャッシュ

• 演算コアを小さくする
• 物理共有キャッシュをやめる

データをチップ上で動かすことの消費電力は非常に大きく、電圧1Vで 64bitデータを10mm 動かすと 60pJ が飛びます。実際には多数バッファ・パイプラインレジスタがあるのでもっと多いでしょう。問題は、既に述べたようにこれはシュリンクしてもかわらない、あるいは配線抵抗が増える分多数バッファが必要になってむしろ電力が増えることです。 A64fx の動作電圧は公表されていませんがそこそこ低いとして例えば 20pJ としても、実際に 10mm 動かしたら配線だけで50GF/W になってしまって、演算器とかでもっと下がるわけです。実際に10mmくらい離れている L2 のバンド幅をあげられないのは当然といえます。

消費電力を 100MW、1GW と増やすわけにはいかないとするなら、スパコンの性能向上のためには電力性能をあげる必要があり、そのためにはデータ移動による電力消費を削減する必要があるわけです。

電力消費を増やす方向の解はないのか？というと、例えば太陽電池は非常に安価になってきており、余剰電力も発生します。従って、余剰電力だけで動かすなら巨大な電力消費でもかまわないのでは？とも考えられます。この方向の問題は、非常に高いピーク性能と冷却能力が必要になり、ハードウェアコストが非常に大きくなることです。蓄電技術の進歩によって常時電力が安価になる可能性も原理的にはありますが、まだしばらくかかるのではないかと思います。

富岳の計画段階、あるいは「京」の計画段階でも、CPU かアクセラレータか、という議論があり、より「使いやすい」CPU でも「目標性能」を実現できる、という論理で「CPU」だけのシステムが開発された、という経緯があります。しかし、「京」、富岳と2世代にわたった「CPUオンリー」のシステムはでは正しい選択だったのか？ということはきちんと検討する必要があります。

もちろん、公式の評価では、ベンチマーク1位を4つも獲得した富岳は素晴らしい成功だった、ということになるわけですが、使う側からみると既に述べたように性能がでないマシンです。CPU であることの意義はソフトウェアの大きな変更や新規開発なしで既存のソフトが動くことであるわけですが、富岳は確かに今まで「京」や Intel Xeon で動いていたものが「そのまま」動きますが、高い性能はでない、といっても間違いではないでしょう。「京」では15-20%の実行効率がでていた格子流体コードが富岳では 2-3% まで落ちるとか、「京」では 30-50%の効率だった粒子法コードが 5% 以下まで落ちるといったことは珍しくありません。そのあと非常にがんばって問題点を明らかにし、改善していくと10-15% になることもある、という感じです。

ターゲットアプリケーションも例外ではなく、実行効率で20% を超えるようなものはありません。「使いやすい」はずのCPUオンリーにこだわったことは良かったといえるでしょうか？

世界的にも、単一の CPU コアだけでトップレベルのマシンを構築する、というプロジェクトは存在しなくなっています。アメリカではNVIDIA、Intel、AMDがそれぞれアクセラレータ提供したシステムが現在構築中ですし、中国で既に完成した2つの1エクサ超超システムも、1つはアクセラレータ、もうひとつはSunway で、 CELL が復活したようなデータキャッシュをもたない演算コアをもつ(命令キャッシュはある)システムであり、通常の階層キャッシュがあるメニーコアシステムは富岳だけです。そもそも、「京」と同時期の BlueGene-Q以降、ヘテロジニアスでなくて Top 1 になったのは富岳だけです。

これは、いかにも90年代以降の「失われた30年」の日本らしく、世界の変化、あるいはその原因となっている半導体技術の変化に対する対応が遅れている、しかも、国の多額の補助金が遅れている大企業に集中するため、本来なら対応できる新しい企業や技術が育たず、遅れが深刻化する、ということでしょう。というわけでおそらく我々が「京」、富岳の経験から本当に学ぶべきことはここにあるわけですが、日本という国、そのシステム自体が急に変わることもないでしょうからこの問題は棚上げにして以下技術的な観点から議論します。

さて、そうすると、「CPU」と「アクセラレータ」で何が違うのでしょうか? Intel が Xeon Phi で示してしまったように、同じ命令セット、同じようなSIMD 演算器をもたせると、スカラコアを簡素にして同時命令発行数や実行ユニットを減らしてもさして電力性能は上がりません。

一方で、それでも単純なコアにするのは一定の効果がある、ということはPEZY-SCx や Sunway が示しています。SC は(2までは)1コアに倍精度演算器1つ、Sunway は 26010 では4way の演算器1つで、どちらもそれほど複雑なプロセッサではありません。PEZY は 4/8 way の SMT によってレイテンシを隠蔽する in-order のプロセッサ、 Sunway は色々なことがいわれていますがDEC Alpha ベースであるようです。どちらも、A64fx に比べると1コアの回路規模がずっと小さく、またどちらも独立したアドレス空間にローカルメモリをもつことで、大容量のオンチップメモリを物理的に演算器の近くに置いています。このことが、大容量のオンチップメモリへの高いバンド幅を実現することを可能にしたわけです。

でも、NVIDIA の GPU は、 Intel x86 や Arm と同様な階層キャッシュじゃないか？と思うかもしれませんが、NVIDIA GPU の場合レジスタファイルが L2と同程度か大きいくらいの容量があり、これを上手く使わなければ高い実行効率が上がらないのは皆様ご存知の通りです。L2 は遠くてバンド幅が小さい(B/F で1程度かもうちょっと低い)し L1 は非常に小さいので、レジスタファイルがのデータ再利用が鍵になります。逆にいうと、そういう構成なので電力性能をあげられるわけです。

PEZY-SCx や NVIDIA GPU の例からわかることは、階層キャッシュが駄目とはいいませんが、そこにデータをおいて計算して高い電力性能を維持するのはもう不可能である、ということです。これは、ここまででみたように理論的には自明で、チップ上でデータを 5mm とか 10mm の距離動かすだけで演算と同程度に電力を消費するからです。PEZY-SCx ではコヒーレンシを捨てることでかなりコア間のトラフィックを減らしてはいます。が、巨大なローカルメモリが性能向上に非常に大きく貢献しています。

PEZY-SCx や Sunway と Xeon Phi (KNL) や Skylake との、キャッシュ以外の大きな違いは演算ユニットの構成です。 KNL、Skylake はどちらも512ビット幅の SIMD 演算ユニットを2つもちろん、これらが論理的に1つのレジスタファイルを共有します。一方、 PEZY-SCx では (SC3 で 128ビット幅になりましたが SC2までは) 64ビットで倍精度演算1ユニットであり、浮動小数点演算についてはスーパースカラーでもありません。register renaming とかしないので物理レジスタの数も少ないです。 Sunway も、 26010 では256ビット幅のユニット1つで、こちらもおそらく renaming はしていないと思われます。

CPU が持つ SIMD ユニットについては、SIMD 幅をどんどん広くすれば電力効率が上がる、というものでもありません。これは。メモリアクセスでアラインしていないアドレスを許し、またレジスタ間の複雑な並べかえ命令(AVX512 のVPERMI2(W/D/Q/PS/PD) 命令や SVE の TBL 命令)を持つので、回路規模がSIMD 幅に比例より速く増えるからです。単純なクロスバーなら SIMD幅の2乗ですし、多段スイッチにしたとしても、配線の総延長はSIMD 幅の2乗かそれより速く増えてしまいます。さらに回路遅延もどんどん増えます。 SIMD 幅が 256-512 ビットで止まっているのはこの辺に理由があるでしょう。

ここでも、GPU は 32 コアとかもっと多くの SIMD 演算をしているじゃないか、と思うかもしれません。これは、レジスタ間(コア間)の並べかえ命令をもたない、ということが大きく貢献しています。コア間がつながってなければ、多数コアを並べても比例してしか回路規模は増えないですし、遅延もふえません。

この辺は PEZY-SCx, Sunway, NVIDIA GPU どれも同じで、演算器間やレジスタ間の複雑な結合を捨てることで回路面積、消費電力、遅延時間のどれも削減していると思われます。GRAPE-DR や MN-Core も同様です。

さて、ではオフチップメモリへのバンド幅ももう悪くなる一方でどうしようもないのか？というと、そうでもなくて少し改善のきざしがみえてきています。メインストリームの製品としてはこれは AMD の 3D V-Cache で、 SRAM ダイをハイブリッドボンディングと言われる技術でCPUダイの上に載せる、本当の3次元実装です。AMD のこの例では SRAM ですが、AP memory は Powerchip Semiconductor の DRAM 製造ラインで同様な3次元実装を DRAM で実現しています。これは基本的に AMD EPYC のキャッシュに使える程度の消費電力で DRAM にアクセスすることを可能にするでしょうから、100GF/W を超えるような電力性能をターゲットにしても B/F で 0.1 程度、現在のGPU 程度なら実現可能と思われます。この場合、 DRAM を非常に多数のブロックにわけて、物理的には面的に並列にアクセスすることで性能を稼ぐわけですから、多数の演算コアがそれぞれのブロックに直結に近い、ローカルメモリに(遅いですが)大容量のブロックが加わったものになります。そうすると、これは古典的な大規模 SIMD プロセッサである ICP DAP やTMC CM-2 と同様な構造をもつことになり、データ並列言語の実装も現実 的になります。

少し「富岳から学ぶべきこと」からは離れましたが、今後の HPC 用プロセッサの方向は基本的には半導体技術、あるいは物理法則の制約から決まるしかなく、

• SIMD でも MIMD でもいいが、複数の演算間の結合をなくす
• 階層キャッシュがあってもいいが、主要なメモリは個々の演算器ローカルにする

• 本当の3次元実装によるDRAM と演算器の距離の削減によって、演算器ローカルのメモリを大きくする