進化したNECのスパコン「SX-Aurora TSUBASA」 - SC19

NECがスーパーコンピュータ(スパコン)「SX-Aurora TSUBASA」が完成したと発表したのは2年前のSC17であるが、今回、NECはSC19のExhibitor ForumでAurora TSUBASAのアップグレードの発表を行った。発表者は昨年と同じMasashi Ikuta氏である。

• SC19のExhibitor ForumでSX-Aurora TSUBASAのアップグレードを発表するNECのMasashi Ikuta氏

SX-Aurora TSUBASAの設計思想

SX-Aurora TSUBASAの設計思想は、強力なメモリとベクトルアクセラレータで実効的に高い計算能力を持ち、消費電力が少なく、設置面積も小さく、プログラムが容易でスパコンの所有に必要なトータルコスト(TCO)が少ないスパコンを作るということである。

NECは一貫してスカラのベクトルホストに計算エンジンである複数のベクトルエンジンを付けるというスパコンを作っているが、Aurora TSUBASAではベクトルホストは独自のプロセサからIntelのXeonに替え、強力なメモリは6個のHBM2で実現することにした。

• SX-Aurora TSUBASAの設計思想は、強力なメモリとベクトルアクセラレータで高い性能を実現し、トータルの所有コストの安いスパコンを実現することである (出典:このレポートのすべての図は、SC19におけるNECの発表スライドを筆者が撮影したものである)

次の図の左側はGPUをアクセラレータとして付けるスパコンの絵であるが、ベクトルホスト(VH)のx86からGPUを呼び出す単位が、ループの1回分の処理のように小さく、頻繁なデータ転送がボトルネックになる。これに対して右側の図のAurora TSUBASAでは、1度、ベクトルエンジン(VE)を呼び出すとその処理が終わるまでベクトルエンジンで途切れずに実行できるので効率が高いという。

なお、初期のGPUではGPUで走るプログラムは終了すると必ずホストに戻るので、この図のような処理になるが、NVIDIAのDynamic ParallelismをサポートするGPUでは、GPUで走っているプログラムから、GPUで走る他のサブプログラムを呼び出すことができるようになっており、毎回ホストに戻る必要は無くオーバヘッドは小さくなっている。

• x86 CPUにGPUを付ける方式では、GPUでの1回の処理が小さく頻繁なデータ転送が必要となりオーバヘッドが大きい。これに対してベクトルエンジンは一連の長い処理を実行できるのでオーバヘッドが小さく、効率が高い

そして、VEにアプリケーション全体をオフロードして実行させることもできるし、x86でアプリケーションを実行しているときにVEで実行する方が効率が良い処理が出てくれば、その部分だけをVEで実行させるというオフロードもできる。

また、アプリケーションをVEにオフロードして実行させている最中にVHでしか実行できないファイルのIO処理などが出てくると、その部分だけをVHにオフロードして実行させるということも可能である。

どのようにしてオフロードを実現するのか？

発表後の質問時間に、どのようにしてこのようなオフロードができるのかというような質問が出た。

Aurora TSUBASAでは、VHとVEの間の接続はPCIeであり、自動的にコヒーレンスが維持されるハードウェアにはなっていないと思われる。従って、VHからVEにオフロードする場合には必要なデータをPCIe経由でVEのHBM2メモリにコピーしてから、制御をVEのコードに渡す必要があると思われる。そして処理が終了すると処理した結果をVEのメモリからVHのメモリにコピーしてからVHのコードに復帰することになる。

このようなコピーの必要性はGPUを使った場合と同様であるが、VEへのオフロードは実行する単位が大きく細切れの転送やプロセサの切り替えの回数が少なく、効率が良いというのがNECの主張であると思われる。

しかし、この質問に対する発表者の回答がずれており、はっきりした回答が聞けなかったのは残念であった。

• SX-Aurora TSUBASAではアプリケーション全体をVEで実行させる左の図の形態、VHで実行しているアプリケーションの一部をVEにオフロードする中央の図の形態、アプリケーションをVEにオフロードするが、VHでの処理が必要な部分はVHで実行させる右の図の形態と、いろいろな実行形態がとれる。なお、VHとVEのメモリは別であるので、実行するプロセサを切り替える前に、PCIe経由でメモリにデータを転送して置くことが必要と考えられる

メモリバンド幅を1.35TB/sに向上させたVE10E

NECは今年、新たにVE10Eというメモリバンド幅を向上させたベクトルエンジンを発表した。初代VE10のModel 10AとModel 10Bのメモリバンド幅は1.22TB/sであったがVE10Eでは、これが1.35TB/sにアップグレードされている。これにより、メモリバンド幅制約で性能を抑えられていたアプリケーションは最大10%程度性能が上がることになる。なお、廉価版の10Cは0.75TB/sであったメモリバンド幅が、VE10Eでは1.0TB/sに上がることになる。

一方、演算性能は、10Aは2.45TFlops、10Bと10Cは2.15TFlopsで変更はない。

• 今回発表されたVE10Eではメモリバンド幅が増強され、10Aと10Bでは1.35TB/sとなった。メモリバンド幅で性能が抑えられていたアプリケーションでは最大10%性能が向上する

次の図にVE10Eの仕様とブロック図を示す。以前のVE10の図との違いは、1.22TBであったメモリバンド幅が1.35TB/sに書き替えられたところだけである。

• 新発表のVE10Eの仕様。変更点はメモリバンド幅が1.22TB/sから1.35TB/sになった点だけである

水冷式Aurora TSUBASAが登場

そして、もう1つの新製品は、2Uの筐体に8個のVEを詰め込んだ水冷の「Aurora 1E」である。この図のようにラックに18台搭載すれば144VEを収容でき、演算能力は350TFlops、メモリバンド幅は194TB/sとなり、B/F比は0.554Byte/Flopsというメモリリッチなスパコンとなる。これまでの8VEサーバは4Uの高さがあったが、それが半分となっており、体積当たりの演算性能が2倍に向上している。

Aurora 1Eは、ドイツ気象庁や我が国の核融合科学研究所から受注しているとのことである。

• 新製品のAurora 1Eは2Uに8VEを収容する水冷サーバである。1ラックに144VEを詰め込むことができ、ラック当たり350TFの演算、194TB/sのメモリバンド幅のスパコンとなる

メモリバンド幅が上がったので、Stream Triadの性能は1084GB/sとなり理研/富士通のA64FXを大きく上回った。

• メモリバンド幅が向上したので、1チップ当たりのStream Triadの性能は1084GB/sとなりA64FXを大きく上回る

また、姫野ベンチマークでは339GFlopsとなり、346GFlopsのA64FXとほぼ並ぶ性能となった。なお、NECの図では、Aurora 1Eを2019年とし、A64FXを2020～年と書いているが、発表はほぼ同時であり、どちらが時期的に早いかは難しいところである。

また、NECは10AEという一番クロックの高いモデルで性能を出しているが、選別した最速のCPUで大規模なスパコンを作ろうとすると、クロックの遅いチップが大量に余ってしまうという問題がある。A64FXのクロックは1.8GHzから2.2GHzまで色々な測定値があり、富岳のクロックは、まだ、決まっていないと思われる。この状態で、ここでどちらが速いかなどと言っても始まらない。

• 流体計算の姫野ベンチマークは339GFlopsでA64FXと近い性能になった。NECはAurora 1Eや10AEは2019年、A64FXは2020～年としているが、発表時期で言えばFX700/FX1000も2019年である

後継機の開発を公表

そして、NECは「SX-Aurora TSUBASA 2(VE20)」という後継機を開発する計画であることを明らかにした。

VE20では搭載コア数を増やしてCPU性能を上げるのと同時にメモリバンド幅も増やして、伝統的なNECのベクトルスパコンの高いB/F比を維持する。そして、性能あたりの消費電力を25%低減して、スパコンの所有にかかわるTCOを低減する。

• NECは性能あたりの消費電力を25%低減する次期エンジンのVE20を開発するという計画を発表した。

ただし、VE20の完成時期などについては明らかにされていない。