富士通のA64FX搭載スパコン「PRIMEHPC FX1000/FX700」を読み解く - SC19

12月6日(金)8時26分 マイナビニュース

SC19のExhibitor Forumにおいて、富士通は新スパコン「PRIMEHPC FX1000」と「PRIMEHPC FX700」を発表した。発表を行ったのは、次世代テクニカルコンピューティング開発本部システム統括部の清水部長である。

3種類のA64FXスパコンを有する富士通

これで富士通は、FX700とFX1000という商用のスパコンと日の丸スパコンとして開発した「富岳」というA64FXをCPUとする3種のスパコンを有することになる。これら3種のマシンを比較したのが次の図である。

富岳とFX1000はラック1本に384CPUを収容し、水冷になっている。ラックの寸法なども同じであり、塗装などを別にすれば同じマシンである。

一方、FX700は2Uの薄型のラックマウントサーバとなっている。そして、FX1000/富岳が水冷であるのに対してFX700は空冷で、設置が容易になっている。また、システムのインタコネクトはFX1000/富岳は独自開発のToFu Dであるのに対して、FX700は業界で標準的に使われているInfiniBandを使っている。そして、FX1000/富岳のソフトウェアスタックがFujitsu Technical Computing Suiteであるのに対して、FX700はOpenHPC、BCMと書かれている。

どちらもA64FX CPUを使っているが、ソフトウェアスタックは異なるものを使っており、インタコネクトも異なる。FX1000とFX700は一見、同一シリーズのような印象の命名であるが、別シリーズのマシンと考えた方が良いのではないかと思われる。

CrayがCS500にA64FX CPUを搭載するモデルを発表したが、こちらのマシンの構成やソフトウェアスタックはFX700に近く、富士通のビジネスとしてはFX700の方が中心になると見ているのではないであろうか。

パッケージ1個で1つの計算ノードを構成するA64FX

一応、おさらいであるが、A64FX CPUはTSMCの7nmプロセスで作られ、48個の計算コアと4個のアシスタントコアを搭載するメニ—コアチップである。アシスタントコアと計算コアは物理的には同じコアで、使い方の違いで分けられている。ArmのSVEベクトル演算命令をサポートするプロセサコアで、64bitの倍精度演算で2.7+TFlopsの演算能力を持っている。

メモリは3D積層のHBM2を4個使っており、容量は32GiB、メモリバンド幅は1024GB/sである。ノード間接続を行うToFu DインタコネクトのインタフェースもCPUチップに内蔵しており、A64FXのパッケージ1個だけで1つの計算ノードを構成する。なお、FX700では、ToFu Dインタコネクトの回路は使っておらず、別途、InfiniBandのNICを取り付けていると思われる。

ソフトウェアにおける理研と富士通の役割分担

富岳のソフトウェアは、次の図に示すように、理研と富士通で分担して開発している。大規模スパコンでは、割り込みなどによって処理時間が長くなるノードが出てくると、並列に計算を行っているすべてのノードの処理の完了は一番遅いノードに引っ張られてしまう。このような待ち時間による処理時間のばらつきをOS Jitter(ジッタ)という。

このため、理研はOS Jitterの小さいMcKernelという軽量OSを開発し、計算コアではMcKernelを使っている。一方、IO処理などの割り込みが必須な処理もあるので、こちらはアシスタントコアでLinuxを動かして実行する。

マネジメントソフトウェアやファイルシステムの開発は富士通が分担している。プログラム開発環境は並列プログラミング言語のXcalableMPとMPI通信用のMPICHは理研が開発しており、残りの部分は富士通が開発している。

FX1000のシステムソフトウェアと富岳のシステムソフトウェアの違いは、この図のレベルの表現ではLLIOと書かれたNVM(不揮発メモリ)ベースのファイルIOのアクセラレータの有無で、富岳にはあるが、FX1000には書かれていないという違いがある。

これは、高速のNVMメモリをファイルIOのキャッシュのように使って速度を上げるアクセラレータであり、大規模なスパコンでは必要性が高い。

FX700は、次の図のように、2個のA64FXチップを搭載したモジュールを2個並べて、さらに2段積みにしており、2Uの筐体に8個のA64FX CPUを収容している。空冷であるので、FX1000のように冷却水の給排水の工事が不要で、設置が簡単である。しかし、ラックに20台のFX700を搭載しても160 CPUであり、1本のラックに384CPUを収容するFX1000の方が設置密度は2倍以上高くなり、大規模なシステムを構成する場合はFX1000の方が適している。

そして、FX700は、前にも述べたように業界標準のInfiniBandネットワークを使い、OpenHPCやBright Cluster Managerなど、オープンなソフトウェアを使っている。

A64FXとSPARC64 XIfxの性能比較

A64FX CPUの性能であるが、京コンピュータに使われたSPARC64 XIfx CPUと比較すると、倍精度で行列積を計算するDGEMMでは2.5倍の性能、メモリバンド幅はStream Triadで840GB/s、流体力学計算で使われるCombined Gatherでは3倍、気象計算で性能に効くL1キャッシュのバンド幅では2.8倍、地震計算で効くL2キャッシュのバンド幅で3.4倍、マシンラーニングで使われる32bit浮動小数点数を使った畳み込み計算では2.5倍の性能になっている。

そして、京コンピュータのCPUは8bit 整数(INT8)の計算をサポートしていなかったので公平な比較ではないが、INT8で畳み込み計算を行う場合は9.4倍の性能が得られる。なお、これらの数値はA64FX CPUのクロックは1.8GHzで測定したものであり、クロックが上がればさらに性能が上がると思われる。

A64FXの性能はどれくらいなのか?

次の図は姫野ベンチマークという非圧縮流体計算のカーネルの計算性能を比較したもので、京コンピュータの1CPUでは、20GFlopsの性能、24コア、2.7GHzクロックのXeon CPUの2ソケットサーバでは85GFlopsの性能であるが、2.2GHzクロックのA64FXは1CPUで385GFlopsと京コンピュータのCPUの約20倍の性能となっている。また、競合するNECのSX-Auroraは286GFlops、Tesla V100 GPUは305GFlopsであり、FX1000は、それらよりも3割程度高い性能を持っている。

次のグラフは、ToFu DインタコネクトでMPI_Send/Receiveを行った場合のレーテンシとバンド幅を示す。下の2本の折れ線グラフはスループットを示すグラフで、横軸はメッセージサイズである。富岳はメッセージサイズが小さい領域では京コンピュータの2倍程度のスループットを示し、1MBの大きなメッセージでは京コンピュータが4.8GB/s程度であるのに対して富岳は6.4GB/s程度となっている。

上の2本の折れ線グラフはMPIでピンポン通信を行ったときのレーテンシを示すもので小さいメッセージサイズでは、京コンピュータは1.3μs程度であるのに対して、富岳では1μs程度に短縮されている。そして、メッセージサイズが大きくなると、富岳の優位は増大していく。

次の図はMPIでブロードキャストを行った場合のバンド幅を示すグラフである。京コンピュータのToFuインタコネクトではデッドロックを避けるため+X、+Y、+Zの3方向に同時にデータを送っており、この3方向への通信の繰り返しで全ノードに同一データをブロードキャストしていた。これに対して、富岳のToFu Dでは同時に±X、±Y、±Zの6方向にデータを送るアルゴリズムを考案し、バンド幅を改善した。

右下の3つのグラフは、上から順に、富岳での6方向同時送信アルゴリズムを使った場合の性能、富岳のToFu Dインタコネクトで京コンピュータの3方向同時送信アルゴリズムを使った場合、京コンピュータのToFuインタコネクトのブロードキャストのバンド幅を示す。なお、ブロードキャストする範囲は384ノードとした測定の結果である。

100MBという大きいデータのブロードキャストでは、京コンピュータの場合は10GB/sを少し上回る程度であったが、富岳で6方向同時送信アルゴリズムを使った場合は36GB/sと3倍以上に性能が向上している。

次の図は、各ノードの計算結果の合計を計算して、その結果を全ノードに送るMPI_Allreduceを384ノードで行った場合の所要時間を示すグラフである。右側のプロットの横軸はAllreduceを行うベクタの長さである。京コンピュータでベクタ長が2以上の場合は、Allreduceに50μs〜60μsかかっているが、富岳ではToFu Barrier Interfaceを使った場合は、倍精度のFP64の場合は最大でも35μs程度で、ベクトル長が30以下の領域ではほぼベクトル長1当たり1μs程度の傾きになっている。ベクトル長が短い場合のAllreduce時間が大幅に短くなっており、性能に大きく効きそうである。

OS Jitterを減らすため、Tickを使って処理を開始するやり方を使わないようにし、不必要なデーモンやサービスを止める。加えて富岳ではアシスタントコアにOSの割り込みやデーモンの実行をオフロードした。x86で普通のOSを使った場合はジッタ(タイミングノイズ)の観測された最大値は873μsであるが、京コンピュータの場合は85μsに減少させた。富岳ではこれをアシスタントコアの使用などで37μsに減少させている。これは観測されたジッタの最大値であるが、平均のノイズ比では、x86が3.7E-03であるのに対して、京コンピュータの場合は6.6E-5と2桁あまり減少しており、富岳では7.1E-7と京コンピュータからさらに2桁小さくなっている。

図の右側の散布図はオレンジがx86システムのノイズを示し、水色が富岳のジッタを示している。

進むオープンソースアプリケーションの移植

次の表はArm HPC Users Groupに公表されているアプリケーションの移植状況を示すものである。ビルド環境を多少変更する必要があるものも半分程度あるが、GCCを使った移植はすべて完了している。また、富士通コンパイラでの移植も、環境の変更やソースコードの変更を必要としたものが多いが、すべて移植ができている。

LLVMとArmコンパイラでも移植ができていないのはSiestaとCP2Kだけで、OpenMXが作業中という状況である。ということで、オープンソースのアプリケーションの移植性も良好なようである。

次の棒グラフは7種の代表的なオープンソースのアプリケーションの性能を、A64FX 1ソケットと24コア、2.9GHzクロックのXeon 2ソケットで比較したものである。Xeonの方を1.0に正規化しており、オレンジのA64FXの棒グラフがA64FXの性能比を示す。

この7つの棒グラフに見られるように、MPASではわずかにXeonが勝っているがそれ以外のアプリケーションではA64FXの方が1.1〜1.4倍の性能となっているものが大部分であり、ABINITでは1.8倍の性能が得られている。

A64FXの性能が高い理由として、メモリバンド幅が高いことと、長いベクトルを扱えるので効率的に処理が行なえることを挙げている。

高性能でも低消費電力を実現

また、A64FXのプロトタイプ機がGreen500で1位になったように、A64FXは電力効率が高いことも大きなアピール点である。次の図はA64FXと前述のXeon 2ソケット機で、7種のオープンソースアプリケーション実行の電力効率を比較した棒グラフである。このグラフに見られるように、SPECFEM3Dの2.3倍からABINITの3.7倍まで、いずれもA64FXはXeonに比べて圧倒的に高い電力効率を示している。

理研と富士通は64bitのArmアーキテクチャでビルドできるオープンソースソフトウェアを増やす努力をしており、現在、GCCコンパイラでは3,451のソフトウェアの内の2,387(69%)のソフトウェアがビルドできるようになっている。富士通コンパイラでは2,072(60%)のソフトウェアがビルドできる。X86 GCCでは2,479(72%)であり、AArch64 GCCも69%まで来ており、かなり近づいていると言える。

富岳はその名前に背かず、最高レベルの性能でアプリケーションを実行できる。そして、Armのエコシステムを利用して多くのアプリケーションを利用できるようになっている。

富士通は富岳の製造を開始しており、PRIMEHPC FX1000/FX700という商用スパコンも発表した。また、CrayがA64FXを使うCS500クラスタスパコンを発表し、A64FXの活躍が期待される。

マイナビニュース

「スパコン」をもっと詳しく

「スパコン」のニュース

トピックス

BIGLOBE
トップへ