質を取るか量を取るか?(スパコンのネットワーク)   

2007年9月13日



☆久々のハムフェアで友人に言われたこと。   
皆様、今年の夏は本当に暑かったですね〜。 ここ数日、ようやくよく寝られるようになりました。

今年はラニーニャ現象の影響で猛暑。 しかも、ニュースを見ていたら実はラニーニャ現象の他に猛暑化を促進する現象として ダイポールモード現象というのがあるのだそうで、 今年はこちらも盛大に発生しているのだそうだ。 道理で観測記録更新の猛暑が続くわけだ。

今年1年の現象だけを見て地球温暖化の影響どうこうというのは言えなくて、 科学的には統計的に正しく解析しなければ結論は下せないのはわかっているつもりなのだが、 ここまで暑いとついつい地球温暖化の影響を考えてしまう。 観測史上初...とか言われても、もう毎年のことでもう慣れっこになってしまってあまり驚かないのだが、 さすがに今年の暑さにはビックリだ。

なにか涼をと思うのだが...寒いのは当サイトの財布の中身だけ。 前回は久々の大型購買で大画面液晶テレビを購入したので、ついに当サイトの残業代の残金も底をついたというわけだね。

そうそう、液晶テレビといえば東芝がシャープと提携してシャープから液晶パネルの供給を受けるそうな。 これは当サイトが液晶テレビの話を前回に書いて1週間もたたないうちに発表された話である。 当サイトは事ここに至ってはIPSパネルとVAパネルの差はほとんど無いと判断したが、 東芝もIPSパネルとVAパネルで実質的な画質差は無くなったと判断した証拠だろう。 プラシーボ効果で「やっぱIPSはVAより視野角抜群にいいっす。」とか「やっぱVAはIPSよりコントラスト抜群にいいっす。」 なんて書いていたら笑われるところだったかもしれない。(笑)

シャープは製造ライン世代的にリーディングカンパニーで、その優位性は画面サイズが大きくなるほど力が発揮される。 逆に東芝は自前の液晶パネル製造ラインを持っておらず、IPSアルファに対する共同出資のみ。 IPSアルファで調達できないサイズのみLG製IPSパネルで代用している。 (この件は前回は勘違いしてた模様。レグザ47Z20はパネルサイズからみてLG製IPSパネルの可能性大。)

しかも、東芝には液晶パネルより優先して設備投資したい分野がある。 すなわちNAND型フラッシュメモリではリーディングカンパニーなのだ。 こちらもつい最近四日市工場への追加設備投資を行ったばかりだ。

つまり、液晶パネルよりはフラッシュメモリの設備投資を優先したい東芝としては、シャープとの業務提携は少ない資金で 品質的に信頼できる液晶パネルを確保できる話だし、シャープとしては最新鋭(第10世代)の堺工場での巨額設備投資に対するリスクマネジメントとしてこの提携は重要だろう。 同じ外販でも、東芝に外販した方が低開発国向けに外販するより価格下落リスク面でも供給量安定性の面でも技術流出面でもリスクが格段に少ないハズである。

シャープの第10世代液晶パネル製造ラインといい、東芝の四日市工場ライン増設といい、 設備投資額が巨額になる一方のこの世界では、設備投資として世代サイクルを回し製造ラインを常に最新鋭に保つことはきわめて重要であり、 今回の提携も大画面化がますます進む現状が続く限りWIN-WINの関係を築けるハズだ。 (液晶パネルだけ見れば東芝は損な役回りだけど、この提携のおかげでそれ以上の利益をフラッシュメモリから得られるハズだ。)

テレビが家電の主役の時代はまだまだ続くのかな? PC危うし!

というわけで、当サイトの手持ち資金は47inch液晶テレビへの巨額投資でスッカラカン。 秋葉で散財とか、避暑地に旅行とか、暑気払いに大枚は叩けない。

そんな中、友人が久々に暑気払いにハムフェアに誘ってくれた。

今回の会場は東京ビッグサイト。 「ゆりかもめ」はいつ乗っても都市風景が楽しめるし、結構乗車率も高くて地域的な人気度も相変わらずである。 当日は猛暑日だったのにお台場は人であふれかえり、相変わらずの人気スポット。 ゆりかもめから見えるフジテレビの球体展望室は信じられないほどの長蛇の大行列。いったいあれは何時間待ちなんだろうかね???

ただ、東京ビッグサイトまで行くと人が減ってきた。 ハムフェアに最後に行ったのは4年ほど前だったように思うが、 残念ながらこちらは開催規模縮小傾向に変わりないようだ。 (団塊世代大量退職で縮小ペースは少し鈍ったようにも感じたが...)

当サイトはアマチュア無線はやらないのだが、ああいう技術世界の趣味は特に子供にお勧めしたいところだ。 なんせ楽しみながら無線工学の勉強にもなるというゲームよりよほどためになる趣味なんだけど、 教育的な見地から見た認知度が低いのは残念だと思う。 (残念ながら子供には全然人気はなくて、会場には若年層はほとんどいない。ハムフェアも少子高齢化が進んでいる。)

で、お誘い頂いのメールで友人が一言。「いや〜、大変だね。」

どうやら当サイトのサイト運営の事を言っているらしい。 まぁ、偉い先生から反対意見の論陣を展開されたりいろいろあったから、 嫌気がさして更新ペースが鈍ったり内容が当たり障り無いものになったりするのを心配してくれているらしい。 ありがたい事だ。

☆質を取るか量を取るか?   
というわけで、今回はスパコンネタで行ってみたい。 そんなことを言われると、書くつもりのないネタまで書く気になるのが当サイトの性格である。 (なんせ、東大将棋4に40連敗しても最強モードを変更しない性格なんだから。変な事書いて笑われるのも性分の内。)

今回考えてみた話題はネットワークだ。 スパコンのCPUとメモリの話については当サイトの意見を Byte/FLOPが決め手(京速計算機考その2)で述べたが、 ネットワークについては書いた事がなかったからだ。

さて、次世代スパコンのネットワーク結合網を考える上で最も重要な基礎ポイントは何だろうか?

で、一番の基礎、というか第一歩の考え方。 それは、「ネットワーク結合網は必要悪。」というごく当たり前のことだろうと思う。1)

ネットワークによる通信はデータをやり取りしているだけで演算をしている訳ではない。 ここに投資するハードウエアは理論ピーク性能から見たら性能を下げるだけのお荷物である。 だから、無くて済むなら無い方が良い。 が...並列計算機である限りは実際には無しでは済まされないハードウエアでもある。

この場合、考えなければならない問題の本質は2つあると思う。 ハードウエア資源をどれくらいの割合でネットワークに投入するのがベストなのだろうか?という点と、 どのように投入するのがベストなのだろうか?という点だ。

前者は全ハードウエア資源に対するネットワークへの最適資源配分の問題、 後者はネットワーク内での最適資源配分の問題である。

まず、今回は後者のネットワーク内での最適資源配分の問題を大雑把に考えてみた。 これは、ネットワークへのハードウエア資源配分比率は既に決まっているとして、 それを、ネットワークバンド幅を減らしてもトポロジ的に優位なネットワークとして配分するのが有利か、 それともトポロジは低次元なものに抑制して、その代わりネットワークバンド幅などに 配分する方がいいのかという問題だ。

同量のトランジスタ資源をトポロジ的に有利な状態として投資する場合と、 バンド幅的に投入する場合を例に考えてみよう。 (レイテンシはハードウエア資源量に比例して決まる話では無いから、今回は同一として無視する。)

トポロジにはいくつかの種類がある。

地球シミュレータやNWTで採用された単段クロスバ。 CP-PACSで採用された多段クロスバ。 ASCI計画で主流だったファットツリー。 現在世界最速のBuleGene/Lで採用された3Dメッシュ(と、グローバル・ツリー。)。 CrayX1E等で採用されたハイパーキューブ。 大雑把に見ると、トレンド的にはメッシュかファットツリーの採用例が多いようだ。

これらを大雑把に分類してみよう。 非常に大雑把ではあるが、一番簡単な分類はノード数に対してハードウエア量のオーダーがどうなるかだろう。 O(n)のクロスバ系、O(n・logn)のファットツリー系、O(n)のメッシュ系といった具合だ。 単段クロスバやオメガ網のような全ノードを等価に扱える均一アクセス系と、メッシュに代表される不均一アクセス系という 分類も考えられるが、ハードウエア資源配分の観点で見るとすればノード数に対する次元で考えた方が評価しやすいと考える。

対するバンド幅はどうだろうか?

これは大雑把には投入資源量に比例すると考えていいだろう。 初期投資という面を無視できると近似すれば、回路を並列化して結線も複数使用すればいいだけの話だからだ。

これを考える場合に問題となるのは、ネットワークにおける通信の状態がアプリによってバラバラという点だと思う。 通信の粒度がアプリ毎に違うのはもちろんのこと、差分法のように不均一アクセス系のシステムでも問題の起こりにくい 最隣接ノード間通信だけで話が終わるアルゴリズムとか、FFTのように 不均一アクセス系では苦手な遠隔ノード間で多量のデータ通信が必要なアルゴリズムとかでも状態は変わると思う。 また、スキャッタ・ギャザーに代表されるように、 転送データ量の少なさの割にシステム全体に占める通信ロスの大きい作業が大部分を占めるアルゴリズムもある。

だが、何を評価基準にするかで結論がコロコロ変わるのはまずい。 評価基準となるアプリはなるべく多めが良いと思うのだが、 なんせネットで得られる情報以上のものは入手できない身分なので、 ベース情報量の少なさはご容赦いただきたい。

まず参考になるのは以前掲載したこの二つの図だ。 これは Leading Computational Methods on Scalar and Vector HEC Platformsという論文から引用させていただいたものだが、 これを見るとあることに気がつく。

各種スパコンにおける実効効率のノード数依存性
左図はPARATEC(FPMD法による電子密度計算)、右図はGTC(PIC法による核融合シミュレーション)の場合
トポロジはES、SX-8がクロスバ、X1、X1Eがハイパーキューブ、それ以外はファットツリー。

それは、効率の絶対値には差があってもスケーラビリティーには大差がないという点だ。

この論文での効率はシステム全体での効率なので、これがネットワークの性能に起因するものかどうかは単純には言えない。 特に、ベクトル、スカラではベクトル機の方が効率面では高い値を示す傾向にあるから、 ネットワーク性能を考える場合には注意が必要だ。

だが、この点を注意してもスケーラビリティーに大差がないという事が何を意味するのだろうか?

それは、少なくともノード数が増える場合にスケーラビリティーの観点から有利なネットワークトポロジという、 高並列化に都合の良いトポロジは無さそうだという点だろう。 コストを無視すればトポロジ的にはもっとも優秀と思える単段クロスバを持つ地球シミュレータも、 スケーラビリティーの観点から見た場合に限れば飛び抜けた高性能を誇っている訳ではない事がわかる。 (ハードウエア規模がO(n)の単段クロスバは、 ノード数に比例する形で効率が他機種より改善しないと本質的にはスケーラビリティーが成立しているとは言えないと考えられる。)

すると、スケーラビリティーという観点から見た場合は、 オーダーの低いトポロジでも何とか我慢できそうという推測が成り立つ。

今後のスパコンを考える上で必然なのは多かれ少なかれノード数は増えることだ。 地球シミュレータではベクトルプロセッサのおかげでノード数を抑制でき、 そのおかげで単段クロスバという高性能だがそれ故に物量の多いトポロジを使用してもシステムが破綻する事は無かった。 しかし、地球シミュレータのネットワーク規模はシステム的にほぼ限界に近いとも言える。

現に、2002年稼働の地球シミュレータは大規模システムで最後の単段クロスバ採用スパコンである。 当時の段階ですらスカラー型を中心としたASCI計画のスパコンではファットツリー等がメインであり、 単段クロスバの採用例は(当サイトの知る限り)無かった。

これは、スカラー型はどうしてもベクトル型よりもノード数が増える傾向になるため、 バンド幅などを満足させるだけで手一杯で、 より高級なトポロジを採用できなかったためであると推測できる。

つまり、ノード数が増える中でノード数を抑制することで高級な結合網を採用できた地球シミュレータではあるが、 さらにこの先のレベルで同じシステムを構築することはもはや不可能とも思える。

で、最初の検討に戻ってみよう。 ハードウエア規模を増やさずに高級なトポロジを採用するためにはどうしたらいいのであろうか? たとえば、無理に単段クロスバを使用しようとすればノード数の2乗に反比例する形でネットワークのバンド幅を減らせば、 一応はハードウエア量を増やさずにノード数の増加に対応させる事ができる。

ここで、二つの例を考えて比較してみよう。 ハードウエア規模が大きくなる事を厭わないならば単段クロスバを採用すればいいが、 規模的に間違いなく破綻してしまう。 で、ハードウエア規模を同じと仮定して、 トポロジがクロスバでバンド幅を減らしたネットワークと、 バンド幅は同じで次元を落としたネットワークの場合だ。

低次元トポロジの代表は仮にここではメッシュとしてみる。(まともに使えそうなトポロジの中では一番オーダーが低いから。) メッシュの次元はO(n)だから、O(n)のクロスバと比べるとハードウエア量はO(n−1)で済む。 つまり、ハードウエア規模を同じとするとクロスバ側はバンド幅をO(n−1)に減らさなければならない。

この場合、どちらの設計思想が高性能を維持できるのだろうか?

まず、ネットワークのバンド幅は必要以上に高くても性能向上に寄与しない事は明白だ。 だから、まずアプリの粒度毎に必要な値の上限値が存在する。 つまり、バンド幅をO(n−1)に減らしても必要なバンド幅を維持できれば 高級なトポロジでバンド幅を減らした方が良いと言うことだ。 メッシュは遠隔転送で性能が出にくいから、バンド幅さえ不足しなければトポロジ的な制約を逃れるためにはクロスバの方が良い。

しかし、逆に不足した場合はどうだろうか?

ネットワークのバンド幅が不足するとその部分が律速になる。 つまり、コンピュータの総合性能はもっとも遅い部分で決まるの原則を考えれば、 ネットワークバンド幅がシステム全体の効率を決めてしまうことになる。

ほぼすべてのスパコンでネットワークの全ハードウエア規模はノードのそれより小さい事から、 ハードウエア的に少ない部分がシステム全体の性能を決めてしまうという事になる。 この状態ではおそらく多くの場合で総合性能はバンド幅の低下にほぼ比例するだろうから、 クロスバの性能はメッシュのO(n−1)からトポロジ的な優位分を差し引いた数値分だけ低下する。

演算能力の割にノード数が少ない地球シミュレータでさえノード数は640である。 次世代スパコンではこの域を桁で超えるだろう事は想像できるから、その場合の性能低下はお話にならないレベルであろう。 トポロジ的な優位性はあるだろうが、それで性能がノード数倍も回復するケースはなかなか無いだろう。

その理由は上記の図だ。 図の差はネットワーク以外の寄与も含んでいるが、この差がすべてネットワーク・トポロジの差だったとしても 効率でせいぜい数十%の違いである。トポロジ的な優位性はあったとしても桁では効かない場合が多いと思われる。 (この2例以外にも十数例のケースを数報の論文で読んでみた。X1Eでスケーラビリティーが悪い例が一部あったが、それを除けばいずれも大差なかった。)

しかし、バンド幅の不足はO(n−1)の話だから、最悪では桁で性能が落ちる事も希ではないと思われる。

つまり、同じ性能低下とは言っても前者の性能低下と後者の性能低下では、 多くの場合でその程度が桁違いに異なる場合が多いだろうと思われる事である。 いつも同じ結末になるとは限らないが、平均的に見ればトポロジを維持してバンド幅を減らした方が性能低下が激しいケースが圧倒的に多いと思われる。

☆諸刃の剣。   
ネットワークバンド幅の不足は最悪では桁で性能が落ちるというケースについて、実例を一例挙げてみよう。 Tera-Scalable Algorithms for Variable-Density Elliptic Hydrodynamics with Spectral accuracy という論文が手元にある。

この論文はBlueGene/Lで非圧縮性流体問題を解くという内容である。 まずここで、BlueGene/LはMD等では高い性能と安いコストを実現している優れたマシンである事を認め、 BlueGene/Lを貶める意図は無い事を述べた上で、この論文の概要を引用してみよう。

この論文で得られた流体問題でのBlueGene/Lの性能は2.76TFLOPSである。 使用されたマシンは65536CPUのマシンであるから、理論ピーク性能は約360TFLOPSである。 つまり、実効効率はわずか0.77%でしかない。

問題は、使用されたアプリケーションがネットワークバンド幅の85%をこの段階で既に使い切っている事である。 つまり、この先どのようにチューニングがなされようとも、根本的にアルゴリズムを変えない限りあと15%しか 性能向上の余地が残されていない。このアプリでのボトルネックは明らかにネットワークバンド幅である。

BuleGene/LはMDのようにネットワークバンド幅がボトルネックになりにくい用途を主目的に開発された機種なので、 元々ネットワークバンド幅が低めである。その上に、物量作戦が根本的な設計思想だから、一台一台のノードは 一般的なスパコンより性能が低い。不足分は通常のスパコンより一桁以上多いノード数で稼いでいるわけである。 この場合は体積表面積効果がデメリットをさらに増幅してしまう。

BuleGene/Lは地球シミュレータと比べると格段に良好な価格性能比と電力効率を誇っている。 しかし、効率がわずか0.77%ではそれもすべて帳消しになってしまうだろう。 このアプリを地球シミュレータなどのベクトル機でテストした例が見つからなかったので正確には比較はできないが、 ベクトル機で流体用アプリを実行した効率は通常30〜80%(AFESでは約65%、3次元MHDシミュレ−ションで約80%を達成している。)程度だろうから、 効率が二桁近くも違う可能性があるからだ。

BuleGene/Lの価格が安い要因の一つにネットワークにコストをかけていないという点が挙げられるが、これは諸刃の剣であろう。 ネットワークにかけるコストを演算性能に投入する設計思想は MD等のネットワークバンド幅が問題になりにくい用途ではコストダウンに寄与する優れた設計と言えるが、 この論文は苦手な流体問題ではここがボトルネックになってしまうという例である。

逆に、地球シミュレータは地球温暖化予測という典型的にネットワークバンド幅が必要な問題をメインミッションにしているのだから、 ここにハードウエア資源を投入することは当然の設計思想である。 MD等ではコストを増大させる悪要因となるが、流体問題でここをケチると同じ問題が発生することは シロウトの当サイトでも容易に想像できることだと思うのだが...

要するに最適設計とはメインミッションのアプリケーション抜きにしては語ることができないというわけだが、 ネットワークバンド幅をケチった場合はこのように桁で性能が下がる場合があり得る。 逆にネットワークトポロジの違いによって二桁近く効率が低下してしまう問題があるかというと、 上図のようにあまりなさそうだということだ。

☆当サイトのお勧めは「まずは質より量。」   
というわけで、ハードウエア資源量の関係でネットワークに投入できる物量に制限があり、 地球シミュレータのような力技が使えない場合、トポロジという質とバンド幅という量のどちらを優先させるべきかというと、 必ずしも常にバンド幅が優位とは言えないけれど多くの場合でバンド幅の確保を優先させるべきケースが多いと思われる。

次世代スパコンのネットワークとして地球シミュレータ型のクロスバが使えないと思われる今、 クロスバを維持したままバンド幅を落とすのではなく、当サイトのお勧め案は トポロジを低次元のもので我慢したとしてもまず第一にネットワークバンド幅を確保することであると考える。

そうそう、BuleGene/Lの名誉挽回のために、そのネットワークに一言追加しておこう。

BuleGene/Lではグローバルツリー結合網がメッシュに併設されている。 BuleGene/Lはノード数が桁違いに多いからスケーラビリティーが成り立つかどうかが成功の鍵になるわけだが、 GTCという核融合シミュレーションでは、なんと32768ノードまできれいに性能がスケールするそうだ。

いろいろとこの問題を考える上で読んだ論文によると、 これはGTCに特徴的な要因として通信内容にギャザーが極端に多いことに起因するそうだが、 ギャザーではグローバルツリー結合網がきわめて効果的に機能することが要因の一つだそうだ。 ギャザーは負荷の大きさの割にバンド幅は問題になりにくい場合が多いが、 レアケースとはいえこれはグローバルツリーというトポロジ的な優位性がバンド幅の優位性に勝る好例であろう。2)

というわけで、バンド幅優位という当サイトの見解も確率的に見て優位と考えるだけであって、 常に必ず成り立つとは限らない。何事にも例外はあるという事だね。 今回は「まずは質より量。」という結論だが、次世代スパコンにもグローバルツリーのように物量的に慎ましやかな質的要因3)は加えたい気がする。

次回できるかどうかはわからないが、いずれ全ハードウエア量に対してどの程度をネットワークに振り向けるべきかも考えてみたい。 (いつもよくやる超簡略化お笑い理論とはいえ、トリ頭を絞ってただいま考え中。まぁ、お笑いネタと思ってくださいな。) なお、今回は耐故障性の面は考えていないので、この点で単段クロスバが優位な点は考慮に入っていない事は一言付け加えておきたい。



1)
どうも我々アマチュアの議論は最初からものすごく重箱の隅をつつくことが多くて、 こういう初歩的な議論が足らないのが反省点だと思う。 重箱の知識があると「詳細まで知ってます。」みたいな虚勢を張る事ができるのが原因だろうが、 これは一番いけない。ベースが間違っていると、いくら詳細な議論をしても間違った結論しか出てこない。 逆に、基礎が正しければかなり大雑把な議論をしても定性的には正しい結論を導き出せることをまず知るべきだと思う。 (もっとも、当サイトのトリ頭では詳細な議論はやろうと思ってもできないって事はあるけどね。)

2)
ただし、同じ性能を出すのに必要なノード数が多いという弱点をカバーしてスケーラビリティーを維持しているけれど、 他のトポロジを採用したマシンより桁で性能が上がるわけではない。(実効効率は約7%程度に留まっている。)

3)
多くの場合でギャザーではバンド幅は不要だから、ツリー的な結合網を加えてもハードウエア量的に破綻することは無いと思われる。 極端な場合だが、転送データ量はたった数Byte程度の事もあるのだそうだ。

−参考文献−
今回のデータは以下からの引用です。
Leading Computational Methods on Scalar and Vector HEC Platforms
Tera-Scalable Algorithms for Variable-Density Elliptic Hydrodynamics with Spectral accuracy