Previous ToC Next

153. 2021/11 Top500、Green500とゴードンベル賞から考える(2021/11/20)

SC21 はハイブリッド開催で、日本からも R-CCS 松岡センター長を始め多くの 参加者が現地にいったようです。私は著者にはいってる論文もないので不参加 です。

まずは Top500、Green500 です。Top500 は富岳が4度目の1位です。但し、中 国の2システムが1EFを超えているらしい、とのことでちょっとそれどういうこ となの？という感じがあります。その1つは Sunway OceanLight であるらしく、 もう一つは Tianhe-3 で、FeiTeng Arm + Accelerator、さらにもうひとつ 開発中の2EF システムは Sugon で、プロセッサは AMD?、ということのようです。

Gordn Bell 賞には中国から 3 本がファイナリストに残っており、全て Sunway OceanLight です。これらの論文から見える仕様は以下のようになりま す。

プロセッサの名前は 26010Pro となったようです。TaihuLight の 26010 の 260 はコア数だったのですが、今度は単に 26010 という型番、ということで しょうか?

26010に比べると、SIMD幅が2倍、クロックが 1.5倍、CG(コアグループ)数が 1.5倍で 4.5倍の性能、ノード数が 40960 から 107520に 2.625倍で全体で 12倍、1.5PF とほぼ富岳の3倍のピーク性能を実現しています。プロセッサ チップの数は富岳の7割程度ですが、単体性能が4倍程度と大きな差があること で3倍のピーク性能になっています。

26010 と比べると、SIMD 幅が倍になったこと以外に大きなアーキテクチャ の変化があるようにはみえず、ソフトウェアの連続性という観点からは好まし くみえます。また、ローカルメモリが 26010 の 64KB から 256KB へ4倍増と、 SIMD 幅の増加以上に増えていることはアプリケーションの性能をだしやすく しているでしょう。ゴードンベル賞ファイナリストにそれなりの実行効率を実 現したアプリケーションがでてきたことはその辺を反映しています。

と、Top500 の話になってないですが、Top500 はそういうわけで中国がエント リしてこなかったので富岳のままです。アメリカはエクサスケールシステム開 発中のはずですが、プロトタイプがでてくる、ということもありませんでした。

Green500 は、大変素晴らしいことに MN-3 が今回も首位で、39.379GF/W とい う驚異的な数字です。もちろん、名目500Wで倍精度 32.8TF なのでこれくらいいっ ても不思議ではないのですが、2020/6には21とかだったので2倍近く数値をあ げています。これはもちろんソフトウェアの改良によるもので、実行効率の向 上と不要な電力消費の削減の成果です。NVIDIA A100 ベースのシステムも、同 様に20.5 から 34.0 まであげていますが、これはハードウェアがかなり変わっ て、今回のシステムはホストが 32コアのEPYC 7543、A100 は 80GB メモリで す。2020/6 には 64コアの 7742に 40GB メモリのA100だったので、完全に別 物です。 7742+40GB A100 のシステムは5位、29.5GF/W となっています。なの で、それでもソフトウェアで1.5倍にはした、ということになります。

理論ピークとHPL性能の差を見ると、2位の A100のシステムは 2.274/2.598=87.5% と極めて高い効率を実現していますが、1位の MN-3 は 2.181/3.390=64.3% でそれほど高くないようにみえます。これはどちらかとい うと設計思想の違いで、MN-3システムとMN-Core プロセッサは AI、特に深層 学習でちゃんと性能がでるように構成されていて、ネットワークやハードウェ ア構成がHPL 向けに最適化してあるわけではありません。HPLを流すにはかなり 小さなメモリ量、細いネットワーク、細いアクセラレータとホスト間接続に なっているので、それで64%の実行効率をだしたPFNのソフトウェアチームの 成果は素晴らしいものです。

まあその、これは言い換えると MN-Core プロセッサ自体にはまだ電力効率向 上の余地がある、ということですが、来年には MN-Core2 もできるのでそちら に注力することになると思われます。

Green500 については、SC直前に AMD が Instinct MI200 を発表して、FP64 で理論ピーク 95.7TF、TDP500W、HPL 42.26TF とのことで単体でこれではいく らなんでも効率低すぎでなんかおかしいですが、(半分しか動いてないという 可能性はあります)それでも電力性能的には高いのでこれがでてきて1位をもっ てくかなと思っていたら、まだエントリがありませんでした。何かトラブルが あって複数ノードではまだ動いていないとかかもしれません。MI250X をつかう Frontiers は搬入・設置も始まっているようですが、どうなっているのか若干 気になるところです。

Sunway OceanLight の消費電力は 35MW といわれており、 何故か富岳とほぼ同じですが、そうすると電力性能は 30GF/W あたりにくる はずで A100 のシステムとほぼ同じかちょっと低いというところです。 これは数字が本当なら驚異で、 A100 も MN-Core も行列演算ユニット をつけてこの数字を実現しているのに対して、通常の SIMD アーキテクチャで それらに匹敵する数字を実現したことになります。もちろん、 アーキテクチャとしてアクセラレータかメニーコアかという違いがあり、 ホストプロセッサやそれとの通信に余計な電力をとられないことの メリットは決して小さくないです。

今回、注目されるのは、 PEZY SC3 がついに姿を現したことです。12位、 24.58GF/W です。これはおそらく EPYC 7702P に 4 SC-3 で50ノード、200 SC-3 チップです。名目ピーク性能が 2.35PF、HPLが1.68PF ですからから、1 チップあたりの名目ピークが 11.75、クロック 700MHz で 128bit SIMD とい うところでしょうか。HPL の効率は 71.5% で、かなり高いですが向上の余地 もありそうです。技術的なこととは無関係な問題で開発が2年近く遅れたのが 惜しまれます。

なお、半導体テクノロジーは、 A100とSC3 が TSMC N7、Sunway は例によって 不明、AMD Instinct が TSMC N6、MN-Core は TSMC 12FFCです。MN-Core だけ 2世代ほどずれてますが、まあその、自分でいうとアレですが、それだけアー キテクチャとソフトウェアに優位性があるということではあります。

さて、ゴードンベル賞は、上でふれたように Sunway OceanLight でのファイ ナリストが3件、あとは Anton 3、 富岳でのブラソフ+N体の宇宙論シミュレーション、 それから Summit でのMD計算です。 富岳でのブラソフ+N体の宇宙論シミュレーションは、 私が代表の富岳成果創出加速プログラムの課題 「宇宙の構造形成と進化から惑星表層環境変動までの統一的描像の構築」 のテーマの1つで、筑波大学の吉川さんが中心となって進めているものです。

ブラソフ、というのは、宇宙論的なニュートリノの分布の時間発展を、 6次元(位置と速度)位相空間の中での分布関数の発展を本当に解くことで 求める、という手法です。通常、6次元の分布を扱う代わりに、 粒子をばらまいてN体系として表現し、その時間発展を追うのですが、 分布関数を直接追う方法は、密度が比較的低いところを正確に解ける、と いう利点があります。その代わり密度が高いところで空間分解能を 稼ぐことが難しいですが、ニュートリノはそれほど密度が高く ならないので低密度領域をきちんと解けるところにメリットがあります。 (原理的にはN体でも色々やりようはある気もしますが、それはまた別の話です)

ブラソフ法では、時間発展を精度よく解くために高次の差分法を使っています。 演算数を論文から推測してみます。(本人に聞けという話はある) 効率が15%、288ノードで96^3*64^3メッシュで1ステップ1.5秒くらいとなって いるので、演算数は 288*6TF*1.5秒*0.15=3.9e14、メッシュ数は 2.3e11 で、メッシュあたりの演算数は1700というところです。 メッシュあたりの変数は基本的に密度だけなので、理想的なキャッシュブロッ キングができると1変数読んで1変数書くのに対して1700演算、800演算に対し て1語アクセスですから、A64fx の6TFの演算性能(単精度)に対して 単精度8GW/s、32GB/s のメモリアクセス性能があればよく、実際にはこの 数十倍の 1TB/s 近くあるので、12-15% の効率は何か上手くいっていない ようにみえます。

ここで、上手くいっていないのはブラソフコードのソフトウェアではなく、 A64fx のアーキテクチャそのものであることを以下に簡単に議論します。 A64fx(R) Microarchitecture Manual から主要なレイテンシとバンド幅を以下にまとめます。 

 ユニット      レイテンシ     ラインサイズ
 FP演算        9サイクル         --
 L1 キャッシュ 8-11サイクル   256バイト
 L2 キャッシュ 37-47サイクル  256バイト
Skylake Xeon だとこんな感じです。 

 ユニット      レイテンシ     ラインサイズ
 FP演算        4サイクル         --
 L1 キャッシュ 4サイクル      64バイト
 L2 キャッシュ 14サイクル     64バイト
 L3 キャッシュ 50-70サイクル     ?
"The L1D cache accepts two loads or one store at a time." とあるので、 あるサイクルには load と store の一方しか実行されません。 Skylake Xeon だと両方実行できるようなので、L1キャッシュの レジスタとの転送バンド幅が Skylake Xeon の半分ということになります。 電力性能をあげるにはL1キャッシュのバンド幅を下げるのは非常に効果的なの で、この選択はハードウェアの性能をあげるためにはよいものですが、 アプリケーションが性能をだすことを非常に難しくしています。非常に単純な 

 for(int i=0; i<n; i++)a[i]=b[i]+c[i];
のようなベクトル演算で、全部キャッシュにある場合、 Skylake だとサイク ル毎に1演算(AVX512ユニットで)は実行できて理論ピークの 1/4 の性能に なるわけですが、 A64fx では2サイクルに1演算しかできないので理論 ピークの 1/8 の性能になってしまいます。差分法だとロード1度で1演算 ということもあり、1/8 ではなくても 1/4 の性能になる、ということがおき がちです。

理論的には、レジスタが沢山あれば、差分式の場合ループ間でロードしたデー タをある程度再利用するようなコード生成も不可能ではないですが、それを阻 むのが A64fx の演算とL1キャッシュの巨大なレイテンシです。レイテンシが9 の演算ユニットが2つあるので、もしも独立な演算が18個あって、それらの結 果をまた次の独立な演算18個が使う、というようなループ構造なら原理的には ピーク性能がでます。単精度だとAVX512で16演算するので、これは長さ 18x16=288 のループが完全に展開されれば、ということになります。但し、アー キテクチャレジスタは32個しかないので、実際にループアンロールしてレジス タを割り当てて、とすると使えるレジスタが2個以下になるので、そういう通 常の展開はできません。論理レジスタ割り当てはしないで、レジスタリネーミ ングとアウトオブオーダー実行によってパイプラインを埋める必要があり、 これは言い換えると複数のループ演算本体(9回とか18回反復)がアウトオブオー ダー実行ウインドウにはいるほど命令数が少ない必要があります。

A64fx の実行ウインドウに相当する Commit Stack Enttry は128で、Skylake の 224の半分強です。これと2倍強の命令レイテンシから、演算器にバブルが 発生しないようなループの命令数が4倍違うことがわかります。この4倍の 違いは非常に大きくて、Skylake では普通にコンパイルすればアウトオブオー ダー実行で性能がでても、A64fx ではコンパイラなり人間なりががんばって ループを細かく分割しないと性能がでなくて、さらに分割することで発生する 余計なロード・ストア命令のスループットが小さいのでさらに大きく性能低下 するわけです。

行列乗算では、1度ロードに対して多数回の独立な積和命令を実行、というの が少ないレジスタ数でもできるので、 A64fx のマイクロアーキテクチャでも理論 ピークに近い性能がでるのですが、それ以外の一般の数値計算では、 L1キャッシュにすべてのデータがあっても、少し計算が複雑になると 上の理由で理論ピークの 15-25% まで性能が落ちることになります。

さらに、L2キャッシュのレイテンシが40サイクル程度と Skylake の L3 キャッ シュ並みに大きいため、アウトオブオーダー実行で L2レイテンシを隠蔽する ことは困難で、事実上プリフェッチができないとL2キャッシュが有効に なりません。

以下は L1-L2 のバンド幅です。 

 バンド幅
 L1->L2       32B/cyle (per core), 256B/cycle(per CMG)
 L2->L1       64B/cyle (per core), 512B/cycle(per CMG)
コア当りで見ると L1-レジスタ間の半分はあってそんなに悪くないようにみえ ますが、CMG あたり12コアあるのにCMGあたりのバンド幅は8倍しかなくて、実 効的には L1-レジスタ間の 1/3 になっていることがわかります。いわゆる B/F 値にすると、L1 が1サイクルあたり4演算に対して 1.5語ですから 3.0、 L2 はその 1/3 の 1.0 となります。

行列乗算では、ブロッキングする行列サイズをキャッシュサイズに合わせるこ とで、必要なメモリバンド幅を減らすことができるので、階層キャッシュを 使って性能をだすことができますが、多くのアプリケーションはそのような 性質をもっていません。このため、 L1キャッシュが上手く使えないと、 上の 15-25% という数値からさらに性能が低下し、 10% 程度になってしまう わけです。

つまり、A64fx のアーキテクチャは、行列乗算には適していますが、多様なア プリケーションで高い実行性能をだすことは

のため非常に困難になっています。これらの中で、ハードウェアコストや電力 性能に大きな影響を与えることなく修正可能なのはアーキテクチャレジスタの 数で、「京」や FX100 で採用されていた HPC-Ace 命令セットのように、128 本のレジスタを直接アドレッサブルにするだけで大きな性能向上が期待できま す。

さて、では、Sunway OceanLight ではその辺どうか？というわけですが、 3つのファイナリストのうち ゴードンベル賞をとった量子計算シミュレータとラマンスペクトル計算は 演算コアが行列行列積で、そこは性能がでるものを使うことでアーキテクチャ にあるかもしれない問題を回避しています。もう一つはトカマクのPICシミュ レーションで、こちらは理論ピークの13%くらいです。とはいえ、通常は メモリバンド幅リミットといわれている PIC 計算で、B/F が 0.02 しかない マシンで13% は素晴らしい性能といえます。

論文では最大規模の 103600 ノードで、3.7e13 粒子・ステップ/秒 となっていてノードあたり 3.6e8粒子・ステップ/秒です。1粒子 24バイトとすると最小限必要なメモリアクセスは48バイトなので 原理的には 17GB/s で、ハードウェアが持つ300GB/s に比べて十分 小さい、とはいえ実際に1read-1write では多分すまなくて数回 アクセスしているとするとかなり限界に近い性能でしょう。 まあその、逆にいうとこれで 200PF でてるので1粒子・ステップあたり 5000 演算もしていることになって、PICにしては多すぎないかという気もします。

PIC コードは「京」の実装は色々あって、効率は 10-20% 程度だったと思いま す。「京」は B/F=0.5 で、それに比べて 1/20 以下の Sunway OceanLight で PIC コードの実行効率があまり変わらない、というのは考えさせられるもの があります。 Sunway OceanLight アーキテクチャはアプリケーションの移植・ 最適化の初期コストは決して小さいとはいえないですが、「京」や富岳のよう な主記憶バンド幅を非常に重視したシステムに比べてピーク性能が高い システムをおそらく安価に構築でき、またレイテンシの大きな階層キャッシュ ではなくフラットにアクセスできるローカルメモリが最大のオンチップメモリ であることで消費電力の削減と高い実行効率を同時に実現させています。

大きなローカルメモリが性能をだすのに有効である、というのは MN-Core も 同じで、アーキテクチャの細かいことはまだ非公開なのでここでは書けないで すが、その原型であるGRAPE-DR ではローカルメモリはレジスタファイルと同 じレイテンシでアクセスでき、演算オペランドに使えます。これがあまり複雑 な最適化をしなくても演算カーネルが理論限界に近い効率をだすことを可能に しています。階層キャッシュはもちろんなく、オフチップメモリとローカルメ モリの間のデータ転送は明示的に指示するわけです。PEZY-SCx は階層キャッ シュを持ちますが、コヒーレンシはとっておらず、さらにそれと別に独立にア ドレスできるローカルメモリを持ち、これが演算カーネルの性能向上には大き く貢献しています。

このようなことを考えると、1コアのマシンからインクリメンタルに進化して きたコヒーレントな階層キャッシュをもつメニーコアアーキテクチャは少なく とも HPC アプリケーションをメインに担うプロセッサとしては限界がきてい るように思います。電力性能をあげるにはレイテンシが大きく(あるいは動作 クロックが低く)、チップ内バンド幅、アウトオブオーダー資源が小さいほう に設計パラメータをふる必要があり、それは実用アプリケーションの効率を下 げることになります。一方、実用アプリケーションの効率を維持すると消費電 力があがってしまいます。さらに、外部メモリに対してある程度のバンド幅を 維持するために、プロセッサ自体の演算性能をあげられません。「京」でもこ の問題は見えていましたが、富岳になってより厳しくなりました。特に、主記 憶バンド幅重視の設計にした結果、計算性能で見た価格性能比が低く、それに も関わらず内部のボトルネックにより様々なアプリケーションの実行効率がそ れほど高いわけではなくなっている、というのはここで議論した通りです。

日本でも富岳の次が議論されていますが、もしもまだ国内開発をするならコヒー レントな階層キャッシュをもつメニーコア以外のオプションを今回はとらない とマーケットで競争力があるものにはならないのではないでしょうか?

富岳はベンチマークよりアプリケーション第一で設計されている、中国のマシ ンはLinpack 専用だ、というようなことをいう人もいた(いる？)わけですが、 実際には富岳はベンチマークでの性能は高くても実用アプリケーションの性能 が問題になるゴードンベル賞はとってなくて、中国のマシンがとってしまった、 ということの意味をきちんと考える必要があります。
Previous ToC Next