Byte/FLOPが決め手(京速計算機考その2)   

2006年6月8日



まずはいつもの余談から。

前回、仕事に行く途中にある丘が実は城趾であることを掲載したが、 なんの情報も無いのでWeb上で調べてみた。 すると、いくつかのお城マニアのサイトにヒットした。

いや、これがとてもおもしろい! いろんなお城をクリックしまくって、時のたつのを忘れてしまった。 当方在住の千葉県成田市には、天守閣があって堀や石垣があるという我々一般人の感覚でいう「お城」はないが、 実は辺り一面城趾だらけだったのだ。車で10〜20分程度の距離に3つも4つも城趾があるなんて... 十年以上住んでますが、不覚でしたなぁ。 時間が取れれば早速今週末に行ってみたいね。

毎日目の前を通っているこの何の変哲もない丘が城趾だったとはねぇ。
とあるお城マニアのサイトに掲載されていた花の綺麗な撮影場所を使わせていただきました。

それにしても、思ったのはお城マニアのレベルの高いこと。 学芸員も裸足で逃げ去るレベルである。 そして、城趾を巡る事に対する熱意も。

こう考えると当サイトもPCマニアとしてそこまで執念があるかというと少し疑問で、 あやかりたいものである。(レベルの低さは言うまでも無いし...)

☆何がボトルネックなのか?   
さて、本題に入って前回からの続きである。 京速計算機では地球シミュレータの単純な拡張案はおそらく通用しないという予想について述べた。

では、過去の方式の拡大方針が使えないとしたら、 どうやって設計すればいいのであろうか?

この問題のポイントはボトルネックを探す事だと考えている。 なぜならば、コンピュータの総合性能は一番遅い部分で決まるというのが当サイトの理解だからである。

スパコンと言えど人間の作り出すものだから当然の事として完全無欠の存在ではない。 (だから時間の経過とともに改良されて性能が上がる。) なので、どんなに優秀なマシンにでもどこかにボトルネックが存在するハズだ。

世界最速のマシンでも同様で、たとえばBlueGene/Lではインターコネクトのバンド幅の狭さがそうだろう。 MD等では世界最速だが、ここがボトルネックとなって流体系計算では1%をも割り込む効率になってしまったりする。

また、地球シミュレータではI/O系の処理能力がボトルネックかも知れない。以前紹介した 大規模アプリケーションプログラムを用いた性能評価 という性能評価データにおけるMADCAPの結果がそれを示唆している。 データを見ると地球シミュレータではI/O処理が多いほど効率が低下する傾向にあることが見て取れる。 演算負荷が上がって相対的にI/O負荷が下がるに従ってシステム全体での効率が回復するのである。

では、京速計算機ではボトルネックはどこなのか?

実効性能=プロセッサ性能×ノード内並列度×ノード数×演算効率

という前回の式に従って、構成部分別に考えてみよう。 まず今回はプロセッサ性能について考えるとして、最大の問題点と思われる性能のボトルネックはどこだろうか?

当サイトはアマチュアで、当然スパコンに関してはドシロウトである。 従って、プロのように複雑な思考を巡らせる事が出来るわけではない。 なので、論理をものすごく単純化してトリ頭でも考えられるような超シンプルなモデルで考えてみることにする。 (というわけで、「モデルがあまりにもシンプルすぎる。」というご苦情は無しでお願いします。)

性能を語る上で一番代表値としてよく出てくるのは理論ピーク性能である。 これに当サイトがスパコン分野で重要と考えるメモリのバンド幅を加えた2点だけに絞って考えてみた。

☆もし...仮に...   
ここで、もし仮に...データ供給能力が無限大で理論ピーク性能が有限のチップがあったらどうなるのだろうか?

もし、理論ピーク性能が8GFLOPSであれば、 データ供給能力は無限大だからここがボトルネックになることはないから、これはそのまま8GFLOPSとなる。 注意点は、データ供給能力は無限大だから1FLOPにつき何Byteのデータが必要かに関わらず常に8GFLOPSとなることだ。

では、ここで逆に理論ピーク性能無限大でデータ供給能力は有限のプロセッサが存在したならば、 どれ位の性能が出せるだろうか?

演算性能が無限大だから、実性能も無限大???

いや、そうではないと思う。いくら無限大の理論ピーク性能があったとしても、 演算ユニットにデータが供給出来なければ意味がない。 つまり、演算性能は演算ユニットへのデータ供給能力が決めることになる。

以前 CELLの相対評価と絶対評価 で書いたように、もっとも基本的な原理を考えると、浮動小数点演算には1FLOPにつき 2ロード・1ストアが必要になる。 演算精度を科学技術演算でもっともスタンダードな倍精度とすると1データが8Byteだから、 これは24Byte/FLOPを意味する。つまり、倍精度の場合は理論的な上限は24Byte/FLOPだ。

また、ほとんどのx86-CPUにはキャッシュがあり、CELLにはローカルストアメモリが、 ベクトルプロセッサにはベクトルレジスタがある。 だから、一時的な局所性のあるデータについては(かなり乱暴な近似ではあるが) レイテンシゼロ・バンド幅無限大と近似して無視することにしてみよう。 するとデータがダイ内部で再利用される場合は遅延無しとなるから、1つのデータが何回再利用されるかが大切になる。

再利用されるデータ分のデータ供給能力を考えなくてもよいとすると、 この場合は再利用される回数分に比例してFLOPS値が伸びる事になる。 つまり、1FLOPあたりに必要なメインメモリの実効バンド幅だけが全体の性能を決める事になる。 本当は24Byte/FLOP必要なデータ供給能力が、キャッシュやベクトルレジスタの寄与により薄められて、 もっと小さな値になるわけだ。

ここまで考えれば大雑把な推定が出来るだろう。 つまり、実効的なメインメモリのバンド幅が8GB/sで 1FLOPにつき1Byte必要なアプリを実行したとすると、 たとえ理論ピーク性能が無限大であったとしても8GFLOPS程度の演算性能しか出ないと大雑把に推定できると思う。 なぜならば、(8GB/s)/(1Byte/FLOP)=8GFLOPSだから...

では、理論ピーク性能も実効的なメモリバンド幅も有限という実際のチップでは...

これは使用しているアプリがどの程度データを再利用しているかによって状況が変わると思われる。 従って、理論ピーク性能と実効バンド幅の関係を、アプリのByte/FLOPを横軸にしてグラフ化して考えてみることにする。

まず理論ピーク性能と実効的なメモリバンド幅を与えてみよう。 ここでは仮にそれぞれ8GFLOPS8GB/sだとしておく。

上記の二つのケースを図にしたのが下記の左図。それぞれ一方が無限大の性能を持つときの推定性能である。 右図は両者が有限の性能を持つときの性能推定概念図。 要するに悪い方の性能で決まるという当サイト的大原則に従った場合である。

問題は両者の分岐点より右に位置するアプリか左に位置するアプリかで 性質が全然違ってきてしまうことであり、おそらく必要な対処方法も全然違ってくる。 当サイトが「グランドチャレンジを何にするかが重要。」と考える最大の理由である。

理論ピーク性能無限大で実効メモリバンド幅有限のチップと、その逆のチップ
実際のチップは両者が有限なので、総合性能は悪い方で決まると考えると...

では、ここで理論ピーク性能、実効メモリバンド幅が一定値のCPUを考えて、 それぞれの性能を上げ下げした場合について考えてみる。 そうすると、それは下図のようになる。

実効メモリバンド幅を一定にして理論ピーク性能を上げて行くと、 出せる最大性能はグングン上がる。

だが、最初の分岐点より右側のByte/FLOPで使用していたアプリでは性能が向上しない。 実効バンド幅が壁となって性能をリミットしてしまうのである。 また、分岐点の位置はどんどん低Byte/FLOP側に移動していく。 つまり、効率よく性能の出せるアプリの種類が減っていくことになる。

逆に理論ピーク性能を変えずに実効メモリバンド幅を強化するとどうなるだろうか?

当然のことだが、理論ピーク性能の上限は少しも上がらない。 つまり、Byte/FLOPの低いアプリに対しては何の効果もないという事である。

だが、分岐点の位置が右側に移動していくので性能を出せるアプリの種類が増えていく事になる。 また、重要なのは一見実性能も上がらないように思えるが、 実はグラフの最初の分岐点より右側の条件で使用していたアプリでは性能が上がる事である。 アプリの種類によっては理論ピーク性能を増やしていなくても性能が上がるということだ。

ただ、問題点はメモリバンド幅を上げることは理論ピーク性能を上げることより技術的に難しく、 またコスト的にも負担が大きいという事実、および、 2ロード・1ストアの3データ/FLOPよりバンド幅を増やしても原理上効果は出ないハズなので、 倍精度の場合では24Byte/FLOP以上は考えなくてもよさそうだという事だろう。 (グラフは100Byte/FLOPまで書いてあるが、24Byte/FLOPでカットオフしてよいということ。)

各性能を固定して一方を変化させた場合
左図はバンド幅固定で理論ピーク性能を変化、右図は理論ピーク性能固定でバンド幅を変化

☆実際のプロセッサに当てはめてみる。   
さて、上記の値は全くの仮想的なものだが、実際にはどんな感じなのだろう。

実効的なメモリバンド幅はあくまで実効値だから単純にメインメモリのバンド幅で置き換える事は許されない。 ただ、これを本気でやろうとするとおそらくはプロレベルの仕事となるだろうし、 アマチュアではデータの入手も不可能である。

従って、ここでは上記の問題点は承知の上で、入手可能な最も近い状況でのデータとして STREAMベンチマークでのメモリバンド幅で置き換えてみよう。 (実際は違った値となるだろうが、傾向自体は変わらないと推定できる。)

前回紹介したレジュメに各種スパコンでのプロセッサ性能が掲載されているので、 この中からItatium2、Opteron、ES用ベクトルプロセッサの3例を引っ張ってみてみよう。

プロセッサ Itanium2 Opteron ES用ベクトルプロセッサ
理論ピーク性能 5.6 GFLOPS 4.4 GFLOPS 8.0 GFLOPS
Stream Bandwidth 1.1 GB/s 2.3 GB/s 26.3 GB/s

また、スカラ機はコストパフォーマンスでベクトル機を追い抜けるというのが主張点なので、 コストについても考えてみよう。

コストパフォーマンスを考える上ではコストを知らなければならないが、 価格についてはデータがあまりない。 当サイトが入手できた数少ない推定ではないコストデータはNACR(米)のデータで、 IBM P690 clusterと地球シミュレータの比較データだ。 (コストパフォーマンス以外にもおもしろいデータがあるので、まとめて引用してみたい。)

このデータによると理論ピーク性能あたりのコストと実効性能あたりのコストで逆転現象が見られるが、 これはベクトルプロセッサの効率の高さによる逆転現象である。 また、消費電力の高さが指摘されているベクトル機の方が消費電力あたりの実効性能が高いが、 これも効率の高さによる逆転現象である。 (ただしNCARで使用したアプリは気象用のもので、ベクトル機がもっとも得意としているジャンルのアプリでの 比較である事には注意する必要がある。LINPACKとは逆にIBM P690側にハンデがきついジャンルであるからだ。)

項目 理論ピーク性能あたりの価格 実効性能あたりの価格 消費電力あたりの実効性能
IBM P690 $2.6/MFLOPS $59/MFLOPS 0.7GFLOPS/KW
地球シミュレータ $8.5/MFLOPS $28/MFLOPS 1.525GFLOPS/KW

このデータから理論ピーク性能あたりの価格は3.27倍地球シミュレータが高価であることがわかる。 従って、スカラとベクトルの価格比を大雑把に同程度として考えてみよう。 もちろんこれは機種によって変わるわけだが、これ以上正確なデータが入手できない以上やむを得ない。 (BG/Lを除けばオーダーまで大きく変わることはないと思われる。)

また、プロセッサの値段を考えた場合 Itanium2とOpteronの価格を同じ3.27倍で補正するのはおかしいという批判が出るだろうが、 「データがないのでごめんなさい。」というのと、 実はベクトル機のコスト高はプロセッサコストに加えてメモリコストの高さにあると言うことを 理解していただければ幸いである。 (つまり、Itanium2とOpteronの価格差は他のコストで薄められる事になるし、 またベクトル機が高価なのは実性能の高さと表裏一体の関係にある。)

実際のプロセッサに当てはめた場合
左は単純に当てはめた場合、右はESを1としてコスト比3.27倍で性能を補正した場合。

と言うわけで、結果は上図のようになった。 非常に大雑把な概算でしかないので傾向程度しか参考にはならないが、 要するに純粋なパフォーマンスでは常にES用ベクトルプロセッサが優勢、 コストパフォーマンスでは使用するアプリの分野によって勝ったり負けたりと思われる。

また、コストを考えないプロセッサ別の性能はES用ベクトルプロセッサが最良だが、 この見解は同一最低ノード数で比較した場合のプロの評価データと一致するのである。

☆理論ピーク性能とメモリバンド幅のどちらが重要か?   
また、とてもおもしろいのはItanium2とOpteronの評価である。

上図を見ていただくとわかるとおり、当サイトの結論ではByte/FLOPの低い領域ではItanium2が優勢、 逆にByte/FLOPSの高い領域ではOpteronが優勢となる。 しかし、理論ピーク性能だけで考えれば常にItanium2が優勢となる。

で、実際はと言うと、これは先に紹介した性能テストデータにおいてPARATECとLBMHDの結果に表れている 通り、当サイトの見解通りの結果になっている。 論文から結果を引用すると、下記の通りとなる。

ベンチマーク LBMHD PARATEC
ES用ベクトルプロセッサ 5.5 GFLOPS 5.0 GFLOPS
Itanium2 0.26 GFLOPS 2.6 GFLOPS
Opteron 0.7 GFLOPS 2.0 GFLOPS
GFLOPS値は1Processorあたりの値
(このデータはインターコネクト性能の差を含むため、なるべくノード数の少ないデータで比較。)

つまり、PARATECはFFTとBLAS3が主演算だが、BLAS3は要求されるByte/FLOPが典型的に低いアプリなので、 この分野では理論ピーク性能の高いItanium2が優勢となる。 しかし、LBMHDは逆に要求されるByte/FLOPSが典型的に高いアプリなので、 メモリバンド幅の点でItanium2に勝るOpteronが優勢となる。

もしプロセッサ性能が理論ピーク性能だけで決まるならばこのような逆転現象は起こらないハズだが、 科学技術計算ではメモリバンド幅もまた非常に重要なことがこの逆転現象に現れていると言えるであろう。

また、LBMHDの結果では地球シミュレータのベクトルブロセッサはItanium2に比べて5.5/0.26=23.90だから23.9倍も優秀であるわけだが、 これは理論ピーク性能だけを見ていたのでは説明が付かないことは明白だろう。 なぜならば、理論ピーク性能では8.0/5.6=1.428だから、たった1.43倍優秀であるだけだからだ。

逆にByte/FLOP値の低いと思われるPARATECではほぼ理論ピーク性能比通りの実測結果となっているわけで、 この領域では理論ピーク性能の向上が性能向上に重要と考えられる。

要するに科学技術計算において性能を増強したい場合、 理論ピーク性能を強化するのが効果的かメモリのバンド幅を強化するのが効果的かはアプリケーション(のアルゴリズム)次第という事になる。 (従って、グランドチャレンジがどちらの領域で動作するのかがアーキテクチャを決める上でもっとも重要と思われる。)

ここで、当サイト的な超単純な近似がどれ位の予測精度を持つものなのかByte/FLOPの値から計算してみよう。 図の左側、つまりBytes/FLOPの低い領域では当サイトの考えでも演算性能が重要だが、分岐点より右側では 演算性能強化よりむしろメモリバンド幅強化だと考えている。従って、右側の例で考えてみよう。

論文によるとLBMHDの演算は1データにつき平均で1.5FLOPだそうだ。 ここで、LBMHDが科学の世界でスタンダードな倍精度演算を使用していたとすると、それは5.33Byte/FLOPである事を意味する。

考えてみると、たとえばキャッシュは初回アクセスでは当然のことながら効果がない。 だから上記の場合では大雑把には3回に1回程度のヒットにしかならないから、 1.5データ/FLOPの演算量ではキャッシュによるアクセラレートはほとんど無い事になる。

つまりこれは、どちらのプロセッサにとっても上図では分岐点より右側の領域となる。 当サイトの解釈が正しければ、理論ピーク性能ではなく実効バンド幅で性能を考えなくてはならない領域で動作している事を示している。

地球シミュレータ用ベクトルプロセッサとItanium2のStreamベンチマークの結果はそれぞれ 26.3GB/s、1.1GB/sである。 この数値を使うと、当サイト的な予測値は26.3GB/s/5.33Byte/FLOP=4.93GFLOPS、1.1GB/s/5.33Byte/FLOP=0.206GFLOPSだから、 それぞれ4.9GFLOPS、0.21GFLOPSとなった。 つまり、当サイトの超簡略化計算による予測は地球シミュレータ用ベクトルプロセッサがItanium2より21.2倍高速という推定値になった。

これを下記に表にしてみたが、これほどのハチャメチャな簡略化を行っている割には 理論ピーク性能比よりずっとうまく実測値を説明できている。 内容はプリミティブなレベルだが、シロウトなりに数値は結構的中していると思うのだが、いかがだろうか?

項目 LBMHD
実測性能
当サイト的
推定性能
Itanium2比性能
(実測比)
Itanium2比性能
(当サイト的推定比)
Itanium2比性能
(理論ピーク性能比)
ES用ベクトルプロセッサ 5.5 GFLOPS 4.9 GFLOPS 23.9倍高速 21.2倍高速 1.43倍高速
Itanium2 0.26 GFLOPS 0.21 GFLOPS −−− −−− −−−

と言うわけで、性能を向上させたいときに何を改善すればいいのかは、 アプリのByte/FLOPによって異なると言うことが今回の当サイトの結論だ。 理論ピーク性能が実効性能をリミットする領域とメモリバンド幅が性能をリミットする領域があり、 その分岐点がプロセッサ毎に異なるという点が重要だと思う。 また、用途によっては理論ピーク性能を上げてもほとんど実効性能が上がらない場合もあり得るということだ。 これが、当サイトが京速計算機のグランドデザインを考える際にグランドチャレンジのByte/FLOPが重要と考える理由である。

我々アマチュアは1GFLOPSのプロセッサAと2GFLOPSのプロセッサBのどちらが優秀かと問われれば プロセッサBと答える場合がほとんどだろう。 しかし当サイトならケースバイケースと答える。 なぜならば、もしプロセッサAの方がメモリバンド幅が大きければ、そちらの方が性能が高いケースが十分考えられるからだ。

先ほどLBMHDの場合において1データにつき平均1.5FLOPである事を引用したが、 このようなデータ負荷の高いアプリはPC用途ではほとんど存在しない。 だから、PC用途ではキャッシュがよく効くし、またキャッシュの改良が非常に重要である。

しかし、科学技術計算では流体などを中心に高Byte/FLOP領域の用途もたくさん存在して、 そのような用途では理論ピーク性能ではなくメモリバンド幅を強化する事が性能向上に重要である。 天才技術者セイモア・クレイが科学技術計算の本質を"It's the Bandwidth."と表現したのは、 まさにこのような意味であると思う。

一番おいしいByte/FLOPの動作点はグラフの分岐点部分であり、 この動作点で動けば浮動小数点演算性能もメモリ性能も無駄なく使い切った形で動作している事になる。 そして、ここより高Byte/FLOP側ではメモリバンド幅が不足し、低Byte/FLOP側では理論ピーク性能が不足している事になる。

つまり、汎用機を作るとすれば何かで冗長な部分が発生するのは避けられず、 それが理論ピーク性能となるのか、メモリバンド幅となるのかがアーキテクチャ毎に異なるという訳である。

で、仕方ないので今回の最終結論。

京速計算機のCPUアーキテクチャだが巨大単一機を仮定するならば、 Byte/FLOPが高いアプリがグランドチャレンジならばベクトル機が断然お勧めだろう。 いくらスカラ機がコストが安いとは言っても、実性能でベクトル機を上回るためには バンド幅比以上のコスト安が必要であり、これはノードの価格が一桁程度安くないとペイしない事を意味している。 (事実、上記に引用したとおり流体分野でのコストパフォーマンスはスカラ機を凌ぐ。)

しかし、Byte/FLOPが低いアプリがグランドチャレンジならばコストパフォーマンスに優れたスカラ機がよいことになる。 メモリのバンド幅が性能向上に寄与しない場合はベクトル機のメモリコストの高さは重荷になる。 これにより、コスト的に身軽なスカラ機は実性能は低くても物量作戦でベクトル機を圧倒できるわけだ。

と言うわけで、要するにグランドチャレンジが決まらない限り当サイトのベストセレクトも決められないという事だ。 決め手はグランドチャレンジアプリのByte/FLOPであると予想する。

次回は複合機というアイディアについて考えてみる事にしたい。



−引用元の参考文献−
"Supercomputing Challenges. at the National Center for. Atmospheric Research". Richard Loft, NCAR, USA
Performance of Ultra-Scale Applications on. Leading Vector and Scalar HPC Platforms.
大規模アプリケーションプログラムを用いた性能評価