怪しげなラッファー曲線もどき。(スパコンのネットワーク)   

2007年10月14日



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

先週、久々に秋葉原に行ってきたのだが、PC関連ショップの衰退は著しい。 PCショップのあったビルが取り壊されて空き地になっていたり、 ビルごと丸々シャッターが降りていたり... 秋葉原自体は萌えブームもあってものすごい人出であり、一時の衰退がウソのように活気づいている。 それだけにPC分野の衰退がかえって目立つのである。

衰退が実感できるのはショップだけにとどまらない。

今回は秋葉原の後で飲み会のお誘いがあったので久々に電車で行ったのだが、 秋葉原駅内の広告も完全に萌え化していて、エスカレータ脇も床面も萌え広告がベタベタに制覇している感じ。 もちろんかわいいのが嫌いという訳じゃないんだけど、 PC関連の広告なんてかけらもありゃしない。これでホントに電気街なのって感じで、寂しいねぇ...

秋葉原という街は常に時代の繁栄を先取りする街だから、 この寂しさも以前にはオーディオマニアやアマチュア無線家が秋葉原で感じた寂しさなんだろう。 だけど、いざ自分の番が回ってくると...何とも...

PCショップもそのうちにものすごくマニアックなショップが秋葉原で数店細々と営業... なんて氷河期が来るのであろうか?

と、思って歩いていたら、TSUKUMO eX前でAMDの「兄貴」がPhenomロードマップについて語るイベントに偶然遭遇。 マニアックなイベントにもかかわらず結構な人手が集まっていた。 当サイトがPhenomを買うかどうかは微妙だけど、CPUのあるべき姿としてGPU混載を主張した以上、 その考え方が間違っていなかった事を証明してくれたお礼としてFusionは必ず購入する予定である。なので、 思わず「AMD頑張れよ。集客力でメイド喫茶なんかに負けるなよ。」なんて心の中で応援してしまった。 当サイトの心の中では秋葉原はあくまでもPCマニアの聖地。PCショップ千年の繁栄を目指してもらいたいね。

☆ネットワーク結合網と税金・税収の関係が似ているところ。   
いや、愚痴っぽくなってすんません。 気を取り直して本論へ。

前々回はネットワーク内の資源配分についてシロウトなりに考えてみたわけだけど、 今回は全ハードウエア資源量に対する最適配分について考えてみたい。

では、全ハードウエア資源のどれくらいをネットワークに投入するのがベストなのだろうか?

これを考える上で参考になったのは大学生時代に某大学商学部の友人から酒席の耳学問で教わったラッファー曲線だ。 ラッファー曲線というのは税率を横軸に税収を縦軸にしたカーブで、税収を最大化させる税率を決めるためのベース理論になり、 最終的にはレーガン大統領のレーガノミクスにも採用された経済理論になったそうだ。

ラッファー曲線
税率は0%でも100%でも税収ゼロになる。
もちろん、実際には50%もの高税率で税収が最大化する事は無いけどね。

で、ラッファー曲線なんて大仰な名前が付いているが、実は最初に言っていることだけならばそれほど難しくない。 税率が0%だと税収はゼロ。これは当たり前だ。 で、税率が100%だといくら働いても全額お上に税金として召し上げられてしまうので誰も働かなくなり、 産業がまったく成り立たずすべての会社が倒産して最終的には結局税収ゼロになる。

しかし、実際には一定の税率で税収があって、それで国家が成り立っているのだから 税率0%と100%の間にはどこかのパーセンテージで税収が最大化する税率があるわけだ。 だから、税率と税収の関係をグラフ化するとX軸の両端がゼロでその間のどこかに最大ポイントがあるカーブを描くわけだね。 (これって、某都市開発シミュレーションゲームで実際に体感できる話だよ。もちろん上図のように50%もの極悪高税率が最適点ということは無いけどね。)

経済学の世界では最終的には論争の末にラッファー曲線は間違いであるという学会定説になるわけだが、 「税率を上げれば税収は増える。税率を下げれば税収は下がる。」という当時の常識を吹き飛ばして、 「税率を下げた方が税収が増える場合もある。」という可能性について研究するきっかけを作った功績は大きいとされている。

当サイト流のいつもの怪しげな発想に基づいてこのアイディアをネットワーク結合網に応用してみよう。

もしネットワークに投入するハードウエア資源量がゼロだとすると、 すべてのハードウエア資源を演算ノードに投入できるから理論ピーク性能を最大化できる。 だが、この場合ノード間でデータのやり取りができないから、 システム全体での性能はノード1台の性能と同じになってしまう。 ラッファー曲線と違って総合性能は完全にゼロというわけではないが、 京速計算機レベルではノード数が多くなる事は必須だからノード数が十分に大きいとすればゼロと近似して良いだろう。

では逆にネットワーク結合網への投入ハードウエア資源量を100%としてみよう。 この場合、演算ノードには1円も投入できなから理論ピーク性能はゼロ。 だから、いくら通信でロスがゼロでも総合性能はゼロ。(当たり前だ。) つまり、ネットワークへのハードウエア資源投入比率と総合性能の関係はラッファー曲線と同じ形を取るわけだね。

なぬ...そんなことは書くまでもなく当たり前?

たしかに当たり前のことだ。 だが、ラッファー曲線もラッファー先生が食事時に思いついて手元の紙ナプキンに書いたのが始まりなのだそうだ。 それが最終的にはレーガノミクスの理論基盤にまでなってしまうわけだから、当たり前のことと言えども決してバカにはできませんぞ。 (というか、いきなり詳細な議論から始めようとするのはマニアの悪癖と言える。)

ネットワーク結合網におけるラッファー曲線もどき。
大規模並列計算機の場合、ネットワーク資源量は0%でも100%でも総合性能はほぼゼロになる。
ただし、どこで最適化されるかはよくわからないが...(笑)

☆トポロジ問題、体積表面積問題、レイテンシ問題は省いて考えてみる。   
では、このラッファー曲線もどきの中で性能を最大化するポイントはどこだろうか?

まず一つ言えることは、当たり前のことではあるが「それはアプリ次第で変わる。」という事だろう。 CPUの理論ピーク性能とメモリのバンド幅について考えたとき最適動作点はアプリのB/F比で変わる事を書いたけど、 同じ事がネットワークにも言えると思う。 グリッドコンピューティングのようにネットワークがADSLレベルでも何ら問題ない場合もあるし、 (ただし、この場合はバンド幅もそうだが、むしろレイテンシが問題だが...) ネットワーク性能がボトルネックとなって全システムの効率を1%以下に押し下げてしまう例も先に紹介した。

ただ、バンド幅の件ではB/F比(メモリバンド幅と理論ピーク性能の比率)が判断基準だけれど、 ネットワークの場合では演算量と通信量の比率となる。 勉強したところによれば、学術的には通信の粒度(グラニュラリティー)と言う。 グラニュラリティーが小さいほどネットワーク性能がボトルネックになりやすい。 (B/F比とは逆に粒度は演算量が分子に来るから、グラニュラリティーは数値が小さい方が通信負荷が大きい事に相当する。) 最適なネットワーク資源投入量はアプリのグラニュラリティー抜きにしては語ることができない。

従って、グラニュラリティーが小さいアプリほどネットワークへのハードウエア資源投入量は増やさざるを得ない。 ラッファー曲線もどきの図の中では、グラニュラリティーが小さい問題を扱うアプリほど最大値をとるポイントは図の右側へ移動していく。1)

また、メッシュトポロジのようにノード間の通信に位置依存性がある場合は、 遠隔通信になるのか隣接通信で済むのかも問題になる。 単段クロスバのようにすべてのノードがトポロジ的に単一距離の場合はこれは問題にならないのだが、 メッシュでは差分法のような隣接通信のみで済むアルゴリズムとFFTのような遠隔ノード間で 大規模データ転送が必要なアルゴリズムでは困難度が相当に違ってくるだろう。

従って、不均一アクセスのネットワークの場合は遠隔ノード間通信の比率が大きいアプリほどネットワークへのハードウエア資源投入量は増やさざるを得ないと予想される。 ラッファー曲線もどきの図の中では、遠隔ノード間通信の比率が大きいアプリほど最大値をとるポイントは図の右側へ移動していく。 (BlueGene/Lにグローバルツリー結合網が併設されているのは、この効果によるダメージを最小限に抑制するためであると思われる。)

そしてこの問題を考える上でもう一つ重要な概念がある。 それは体積表面積効果だ。

たとえば3Dメッシュトポロジで考えるのが一番わかりやすいのであるが、 高い理論ピーク性能を持つノードを少数つないだシステムと、低い理論ピーク性能のノードを多数つないだシステムでは 同じ効率を出すのに必要なネットワークの物量が異なる事は体積表面積効果としてよく知られている。

差分法のように演算に隣接データが必要な場合を考えてみよう。 そうすると、演算量は体積に、通信量は表面積に相当する。 同じ体積の箱を分割して体積と表面積の割合を考えてみると、分割数が多いほど表面積の割合が多くなる。 これと同様に、同じ演算性能のシステムでもノード数が多いほどより強力なネットワーク性能が必要になる。 つまり、低性能ノードを多数使ってシステムを組むとより多くのハードウエア資源を通信のために投入せざるを得なくなる。

このとき重要なのは、ノードが多いときはネットワーク性能を上げる必要があるが、 これはノード数が少ないシステムと同じ性能を維持するために必要な措置であって、 ネットワーク性能が高くても必ずしも総合性能的に高性能にはなるとは限らない事だ。

従って、この効果は(同じ問題を解く場合)ノード数が増えるに従ってハードウエア資源投入量を増やさざるを得ない事を示している。 ラッファー曲線もどきの図の中では、ノード数が多いシステムほど最大値をとるポイントは図の右側へ移動していく。 つまり、通信ハードウエア量の観点から言えばノードの演算性能はできうる限り高性能にして、ノード数を減らすのが理想である事がわかる。

さて、このように考えるべき要素が多いのがネットワークを考える際に難しい点だ。 こういうネタを考える際にネットワークの話を一番最後に持ってきたのには理由があって、 それは当サイトの得意な超単純化という手法が使い難いということだ。 頭の悪い当サイトには、これは結構痛い。

というわけで、難しい条件を簡単にするために条件を減らしてみよう。 まず、ネットワークトポロジは同一として無視することにしてみよう。 また、問題規模は一定とし、ノード性能も同一とする事で体積表面積効果も無視する事にしてみる。

ネットワークへのハードウエア資源投入量を決める要素としてはアプリの粒度で決まるネットワークバンド幅を考えてみる。 ネットワークの性能要因としてはバンド幅の他にトポロジとレイテンシがあるが、 トポロジは先に述べたとおり同一として省略して考える事に決めたし、 レイテンシはどちらかというと創意工夫が効く世界でありバンド幅のように資源投入量に比例する話ではないからだ。

☆怪しげなラッファー曲線もどきを書いて考えると...   
ではネットワークバンド幅と総合性能との関係はどうなるのだろうか? またも当サイトお得意の怪しい話なので、 いつものごとくタヌキ・キツネに化かされない心構えでお読みいただきたい。

この点は以前Byte/FLOPが決め手(京速計算機考その2)で考えた論理がそのまま適用できると思う。 B/F比を通信のグラニュラリティーに、メモリバンド幅をネットワークバンド幅に置き換えて考えれば良い。

つまり、この場合はネットワークバンド幅が足りない内はネットワークバンド幅が総合性能をリミットし、 足りてしまった後は全システムでの合計の理論ピーク性能が総合性能を決めると近似するわけだ。

これを図にすると下図の通りになる。 (問題を簡単にするために、演算ノードとネットワークのみの資源を考えることとし、ストレージ等の資源は無視している。 また、ノード内での性能は理論ピーク性能と一致すると仮定する。)

ネットワーク資源の最適投入比率モデル
ボトルネックが総合性能を決めるという原則をネットワークバンド幅に投入すると...

この図の意味はこうである。 まず、紺線は全ハードウエアをノードに投入した場合に対する理論ピーク性能の効率を意味している。 ネットワークは通信をしているだけで演算はしていないとすると、 ネットワークに投入したハードウエア資源分だけ理論ピーク性能は低下する。 25%の資源をネットワークに投入すれば、理論ピーク性能はすべての資源を演算ノードに投入した場合の75%になるという 全然当たり前の事を意味している。 (この線の意味はきわめて簡単だね。)

で、お次は青線。 これは、ネットワーク資源がグラニュラリティーをどの程度満足させているかを示している。 この図では仮にハードウエア資源を25%投入した時点でグラニュラリティーとバランスがとれるアプリと仮定して図を書いてみた。 すると、25%に到達するまではネットワークバンド幅が総合性能をリミットし、 それ以上では単にネットワークバンド幅が遊ぶだけで総合性能には寄与しないと近似する。

つまり、25%までは比例し、それ以降では(この部分での)効率100%というカーブになる。

そして、では総合性能はというと、ノード内の事情は無視しているので、 ネットワーク効率が100%以下ではネットワークバンド幅×グラニュラリティーが総合性能となり、 100%到達以降では理論ピーク性能そのものが総合性能になる。 (図の左半分ではネットワーク性能が総合性能をリミットし、右半分では理論ピーク性能が総合性能をリミットすると考える。) つまり、紫線のカーブだ。本家ラッファー曲線とは異なり、両端がゼロの曲線とは言ってもなだらかな山形曲線ではなく三角形の形になるわけだね。

で、まずは説明しやすいように横軸を実数で書いてみたが、グラニュラリティーはアプリによって桁で変わるので 横軸を対数化してみたのが下図である。

上図の横軸を対数表示に切り替えた図
通信のグラニュラリティーはアプリによって桁で変わるから、横軸を対数化

この図は最初から「25%の資源をネットワークに投入したところで最適化するアプリの場合」 と最初から決めて図を書いているわけだから、この図が最適なネットワーク資源投入比率を教えてくれるわけではない。

しかし、だからといってこの図が何の役にも立たない役立たずという訳ではない。

最適投入資源量が異なるアプリで実行すると...
安全策型とハイリスク・ミドルリターン型に分かれる。

最適資源投入量を5%(青線)、10%(紺線)、25%(紫線)、50%(黄線)の総合効率曲線をまとめて図に書いてみたのが、上図である。 すると、こんな簡単で怪しげな図でも結構おもしろい事がわかる。

最適資源投入量5%で設計されたシステム(青線)と25%で設計されたシステム(紫線)を比較してみよう。 まず、資源投入量25%のシステム(紫線)を使って、最適資源投入量5%でグラニュラリティーと システムのバンド幅がマッチするアプリを実行する場合を考えてみよう。

最適資源投入量5%のアプリではネットワークに5%の資源を投入したところで最適化するわけだから、 理想的には青線の点Aでシステムが最高効率になる。 このときの総合性能は、当たり前の事ではあるが全資源を演算ノードのみに投入した場合の95%である。

で、このアプリを資源投入量25%のシステム(紫線)で実行するとどうなるか?

青線上で資源投入量25%の点を見てみると、点Bとなる。 つまり、最適に設計されたシステムでは点Aの効率(95%)になるところが、 最適動作点ではない事により点Bの効率(75%)になるわけだ。 というわけで、性能は最適動作点である点Aよりも21%低下する事になる。

では逆に資源投入量5%のシステム(青線)を使って、最適資源投入量25%(紫線)のアプリを実行する場合を考えてみよう。

最適資源投入量25%のアプリではネットワークに25%の資源を投入したところで最適化するわけだから、 理想的には紫線の点Bでシステムが最高効率になる。 点Aより効率が低い値で最適化するのは、グラニュラリティーがより低いアプリに相当するためである。 このときの総合性能は、全資源を演算ノードに投入した場合の75%である。

で、このアプリを資源投入量5%のシステム(青線)で実行するとどうなるか?

紫線上で資源投入量5%の点を見てみると、点Cとなる。 つまり、最適に設計されたシステムでは点Bの効率(75%)になるところが、 最適動作点ではない事により点Cの効率(15%)になるわけだ。 というわけで、性能は最適動作点である点Bよりも80%も低下する事になる。

これは、「ネットワークは理論ピーク性能に寄与しないから、できるだけ資源配分量を減らして理論ピーク性能を高めよう。」 という発想は一見合理性がありそうで、実は汎用機としてはかなり問題のある発想という事を意味している。 それで性能低下が発生しないアプリならば問題はないが、問題があるアプリでの性能低下が激しすぎるからだ。 (「ネットワーク性能を犠牲にしても理論ピーク性能を高めたい、アプリの適合範囲は狭くてもかまわない。」 という用途なら、はじめから専用機として設計する手も十分に考えられる。 ネットワーク性能を絞ったマシンは結局のところ細粒度アプリでは実質的に役に立たない可能性が高いからだ。)

☆ネットワーク資源投入量の最適点からのズレと性能低下の関係は同一のトレードオフではない。   
両者のケースの性能低下が同じ割合ならば話は簡単である。 想定している使用アプリのグラニュラリティーを調査して、グラニュラリティーの平均値で設計すれば良いだけのことである。 だが、非常に示唆的なのは両者のケースで性能低下の割合が全然異なることだ。 この場合の最適設計は結構難しい。

要するに、ネットワーク資源投入比率が高いシステムは最適動作点から効率低下するとしても低下の割合が低く、 汎用機として安定して使えるという事を意味している。 つまり、設計思想としては安全策的である。

逆に、ネットワークへのハードウエア資源投入比率を絞ったマシンはツボにはまるとそこそこ高速だが、 外すと極端に性能が低下するマシンになる事である。 つまり、このような設計はハイリスク・ハイリターン型...ではなくてハイリスク・ミドルリターン型になる。

なぜそのような事になったのだろうか?

それはネットワークへの資源投入比率が50%を超えていない領域で物事を考えているからだ。 この領域ではネットワークバンド幅の方が支配要因としての効果が高い事が原因である。 要するに、紫線の左部分の傾きと右部分の傾きが異なるからこういう事になっているわけだ。

たとえば、最後の図をネットワーク資源投入量50%以上の領域で物事を考えると、 ハイリスク・ミドルリターン型になるのはネットワーク資源投入比率の大きい側のマシンとなる。 この違いの分岐点は使用するアプリにおけるネットワーク資源への最適投入比率が50%を超えているかどうかだ。

では、超えるか超えないかの基準は何で決まるのだろう。 これはこのグラフを書いたときに「ネットワークバンド幅が足りない内はネットワークバンド幅が総合性能をリミットし、 足りてしまった後は全システムでの合計の理論ピーク性能が総合性能を決めると近似する。」 と考えた事に起因する。

総合性能を最適化する資源配分量は、大雑把には以下の3つの条件で決まると考えている。

  1. アプリのグラニュラリティー。
  2. パフォーマンスが評価基準の場合は、理論ピーク性能に投入するべきハードウエア資源をネットワークバンド幅に投入した場合、 どれくらいの比率で置き換えられるのか?
    つまり、1FLOPSのハードウエア資源を諦めてネットワークに回した場合、何Byte/sのネットワーク資源になるのか?
  3. コストパフォーマンスが判断基準の場合は、理論ピーク性能とネットワークバンド幅のコスト構造の比率。
    つまり、1FLOPS分のコストをネットワークに回した場合、何Byte/sのネットワーク資源になるのか?
2.3.は¥と$の為替レートみたいのものである。 2.はハードウエア的に見た交換レート、3.はコスト的に見た交換レートと考えるとわかりやすい。

つまり、アプリ毎に満足すべきグラニュラリティーがあって、 それをパフォーマンスが評価基準の場合はハードウエア的に見た交換レート、 コストパフォーマンスが評価基準の場合はコスト的に見た交換レートで換算して、 それが50%を超えなければグラニュラリティーの小さいアプリを基準に基本設計を行い、 逆に50%を超えてしまったらグラニュラリティーの大きいアプリを基準に基本設計を行うのが良い設計思想... というのが、この図から考察した当サイトの結論である。 (ちなみに、アプリによって超えたり超えなかったりする領域の場合は、どっちで設計しても大差ない領域という事を意味している。)

で、現実問題としてはどうなのであろうか?

アプリ毎のネットワーク資源への最適投入比率自体をこの図は教えてくれる訳ではないから、 図からは50%を超えるかどうかは何も言えない。 ただし、現実のシステムを見てみるとだいたいの見当が付く事がわかると思う。

いろいろ存在するスパコンシステムの内でネットワークコストが一番高そうなのはどのシステムだろうか?  おそらくそれは単段クロスバを使った地球シミュレータであると思われる。 で、その地球シミュレータで全ハードウエア資源に対するネットワーク資源への投入比率はどれくらいだろうか?

地球シミュレータへのハードウエア資源投入比率は演算ノードとクロスバ交換機の床面積比から推定すると 20%強といったところだ。床下の配線は全システムに床が見えない位の配線量でつながっているわけだから、 実際はもう少し高い比率だろうが、さすがに50%を超える事は無いだろう。

コスト的には床面積比だけでは判断が付かないからコストパフォーマンス面はわからないが、 少なくともパフォーマンスの面から考えた場合は50%を超えていないわけである。

また、地球シミュレータは地球温暖化予測という典型的な流体問題をメインミッションにしている。 流体問題は典型的な細粒度問題と言われているから、グラニュラリティーももっとも小さいアプリの典型だろう。

つまり、少なくともパフォーマンスが判断基準の場合は、現状では 使用を想定しているアプリの平均粒度で設計するのではなく、 粒度の低いアプリに重きを置いて設計するのが正しい設計思想ということになる。 (ただし、上図はトポロジ的にはすべて同一の場合での比較と仮定しているからトポロジ的な当否は何も言えないけど。)

また、コストパフォーマンスが判断基準の場合は、現状では理論ピーク性能よりもネットワークバンド幅の方がコストが高い事を考慮に入れる事になる。 この場合は、ネットワークバンド幅を少し諦めるだけで理論ピーク性能は大きく上がるわけだから、 粒度が粗いアプリに特化するならばネットワークのハードウエア量を最小限に止めてその分を理論ピーク性能に投入するのが良い設計と言うことになる。 実際、粗粒度アプリの典型であるMDにおいてそれに特化したBlueGene/Lはそういう設計思想になっているし、 演算性能面でも良い結果を残せている。(つまりは、準汎用機である。)

ちなみに、この場合は上図は横軸がハードウエア資源の投入比率ではなくコストの投入比率で書くわけだね。 で、ネットワークと理論ピーク性能のコスト構造が(現状では)ネットワークの方が高価なことから、 上図よりコスト投入率は高い側のパーセンテージに移行するわけである。 (この場合はコストは一定で、ハードウエア資源量は変化する。)

要するに、現状では理論ピーク性能よりネットワーク性能の方が総合性能に対して(同じハードウエア量ならば)敏感な場合が多いということだね。 これは、地球シミュレータでは苦手な分野が少なく、コストは高いものの多くのアプリで安定した性能が出るという事実、 およびBlueGene/Lはツボにはまるときわめて高性能だが苦手な分野だと1%をも割り込む効率になってしまうという事実と整合性がとれている。

スパコンの世界ではTOP500のLINPACKベンチマークが評価用ベンチとしてもっとも有名なので、 LINPACKで不要なネットワーク性能はないがしろにされる傾向が強い。2) 限られたハードウエア量の中で理論ピーク性能に寄与しない部分にコストをかけると 見かけ上の性能が低下するし、実際LINPACKではレイテンシさえ短ければバンド幅は不要だからだ。 (今回はパフォーマンスを基準としたが、コストパフォーマンスを基準とするとこの傾向は一層強くなる。)

だが、実際のアプリケーションではネットワーク性能は重要であろう。

当サイトはアマチュアなので、多くのスパコンユーザーがスパコン性能の何に不満を抱いているかはよくは知らない。 だがこのことから考えて推測するに、実際のアプリケーションではネットワーク性能、特にネットワークバンド幅が ボトルネックになって性能が出ないという不満は結構あるのではないだろうか?(特にグラニュラリティーの低いアプリで。) ネットワークにハードウエア資源をかけていないスパコンは、システムとしての特性がピーキーになる。 つまり、アプリによって性能が乱高下する。 ツボにはまるアプリのユーザーから苦情は出ないが、ツボにはまらないアプリのユーザーからの不満は強いと考えているのだが、 これはおそらく実態に即しているだろう。

なお、コストパフォーマンスが基準の場合はスパコン内部でのコスト構造がわからないと分岐点である50%を超えているかどうか判断できないから、 データ不足で実態はよくわからない。 だから今回は判断基準をパフォーマンスとさせていただいたけど、コストパフォーマンスが判断基準の場合は おそらくはパフォーマンスが判断基準の場合に比べてネットワークの規模を縮小した方が最適になる方向へ最適点がシフトするだろう。

☆将来のトレンドは?   
ただ、これはあくまで現状分析であって、将来の話となるとどうだろうか?

これは理論ピーク性能とメモリのバンド幅の件とはちょっと事情が異なるかもしれない。

理論ピーク性能とメモリのバンド幅の関係だが、近年のマルチコア化により理論ピーク性能の向上の方がペースが速い。 典型的なのはintelのLarrabeeだ。 このため、バンド幅は絶対値としては順調に向上しているにもかかわらず、 B/F比として見てみると性能は順調?に低下している。(笑)

なので、今後のスパコンはノードレベルで見れば絶対性能は順調に良くなって行くだろうが、 演算効率としては順調?に悪化する事が予想される。 現在のCOTSプロセッサは何らかの形でメモリバンド幅の革新が必要である事は明白であろう。

しかし、ネットワークの場合はどうなのであろうか?

半導体技術は18ヶ月で2倍の性能向上というムーアの法則はよく知られている。 で、ネットワークでこれに相当する経験則としてビルジョイの法則というのがある。 これはネットワーク性能は12ヶ月で2倍の性能向上というもの。

これだけを見るとムーアの法則よりもビルジョイの法則が速い。 なぜならば、ビルジョイの法則自体がムーアの法則よりもペースが速い上に、 ムーアの法則はあくまでコア内の性能向上であるから、 メモリー・ウオール問題を考えれば実効性能はそのペースでは向上しないと思われるからだ。

とすると、現在はシステム全体に対する感度が高いという意味でハードウエア資源として貴重 なネットワークも、将来は関係が逆転して理論ピーク性能が貴重となる可能性もあるのかもしれない。 そうなると、ネットワーク性能は満足していてもピーク性能が不足というケースも増えるだろうから、 現在よりはもっと粒度の粗いアプリに比重を置いた設計思想が重要になる可能性もある。 (上に書いたインチキなラッファー曲線もどきから言えば、ハードウエア資源配分比率に対して感度の高い要因の比重を増すべきだからである。)

もちろん、PCクラスタが超大規模システムで使い物にならないことでわかるように、 ネットワークはバンド幅だけではなくレイテンシも重要である。 ビルジョイの法則はネットワークのレイテンシ効果を含んでいない法則だから、 単純な発想でそうなると考えるのは早計だけど...

秋葉原と同じで、ひょっとしたらスパコンの最適設計もある種の転換点に来ているのかもしれないね。



1)
つまり、以前書いたとおり、MDが主用途のBlueGene/Lはネットワークバンド幅が細く、 流体問題が主用途の地球シミュレータでは太いのは、それぞれのメインミッションへの最適化の結果と言えると思う。 これは、BlueGene/Lを気象用コンピュータとして導入したり、SXシリーズをMD用に導入したりするユーザーが(当サイトの知る限り)無いことからもわかる。 LINPACKという同じ土俵で比較される両機だが、本来ならば両機はそれぞれ異なる分野で使用される機種である。 両機は同じ分野で直接比較できるような機種ではないのである。

2)
レイテンシは重要なので、これは例外として除外する。