CPUの省エネ、後編(CELL、BG/Lを参考に考える。)   

2008年7月21日



☆今年も成田祇園会と佐原の大祭に行ってきた。   
前回は通勤手当問題でチャリンコ通勤を諦めた件を冒頭に話したけど、 万一本当に詐欺状態だとマズイので対策してきた。 出張時や飲み会時のチャリンコ通勤は認められているのでただちに通勤手当の横領にはならないようだが、 「梨下に冠を正さず。」の例えもあるし、やっぱ再開は難しそうだ。

それにしても、この件で思ったのだが、地球温暖化対策というのは科学技術や経済だけの問題ではなく、 法曹界にとっても難問なのだなという事だ。前回述べた通勤手当半額支給制度にしても、 通勤中に交通事故にあったら労災認定をどうするかとか、法律上結構難しい問題があるらしい。 温暖化対策の法律上の難問というと京都議定書に代表される国際法的な問題しか思いが至らなかったわけで、 妙なところから普段は思い至らない分野の方々の苦労について考えさせられた形になった。

さて、と言うわけでまずは気分を変えて余談から行こう。 梅雨明け間近のこの季節、お祭り最盛期に突入である。 ここ北総地方でも、成田祇園会、佐原の大祭など夏本番を告げる祭りが各所であった。 と言うわけで、今年も成田祇園会、佐原の大祭に行ってきた。

新勝寺の前には坂があって、山車が下っていく先には新勝寺が見える。(写真中央)
祭りと言えば露店。当サイト的にお勧めなのは地元漬物屋さんの店頭で売っているキュウリの浅漬け。(写真左)

日本人から季節感が失われて久しいと言われるが、お祭りは日本人の春夏秋冬には欠かせない。 特に夏から秋にかけては最盛期であり、遠出できない忙しい時期でも ちょっと1〜2時間暇な時間があれば楽しめるお気楽レジャーなのだ。 (当サイトも仕事の合間に行ってきた。)

レジャーとしてはお金があまりかからないのも貧乏人の当サイトには優しい。 大規模レジャー施設に行くことを考えたら何分の一の出費で済むもんね。

あと追加するとすれば、レジャーとしては省エネな事かな?  大電力をバカ食いする大型レジャー施設と違って、エコなレジャーである点も時代のトレンドに沿っている。 なんぜ、山車祭りなんて野外でやるから冷房電力ゼロだし、人力で山車を曳いているんだから 炭酸ガス排出ゼロ。(人間は石油や電力は食べられないから、植物起源の炭素を燃やしても温暖化に影響がないのと同じ理屈になる。) まぁ、屁理屈を言えば「露店の発電機はどうよ。」とか言い出したらきりがないけど。(笑)

露店と言えば、成田祇園会では当サイト的にお勧めなのがこのキュウリの浅漬け。 冷えた薄味の出汁に浸かったキュウリが1本100円。 この時期は梅雨の合間で暑い場合が多いし、水分補給の熱中症対策にもグッド。 もちろん、野菜だけにとってもヘルシーだ。美味いですよ。

佐原の大祭は年々観光客が増えている様子。
佐原以外でも川越・真壁なんかは郷土色を生かした観光で地域の活性化に成功している。
地方公共団体経営の観光施設などは、ほとんどが経営破綻している事を考えれば...

そして、佐原の大祭は仕事の都合で夕刻から夜にかけての出撃。 もっとも、当サイト的にお勧めなのは夜の部で、こちらの方が幽玄さが増して癒し効果満点。 やはり夏祭りには提灯がよく似合う。

佐原の大祭ではメインストリートが小野川周辺になっていて、この辺りはCMの撮影に使われる位に 日本情緒に溢れている。石垣の河岸に旧家の土蔵と柳の木がよく似合う、すばらしい風景だ。

佐原の大祭、当サイトお勧めは夜の部。
提灯が醸し出すこの雰囲気、いかにも日本情緒たっぷりで癒し効果も抜群。
昼の部も良いが、夜の部が断然お勧め。

お祭りに行って思うのだが、ここ佐原もそうだが、川越、真壁といった地方都市が郷土色を生かして 地域活性化に成功している。一方、地方公共団体経営の公営レジャー施設なんかはガラガラで、 ほぼすべての施設が事実上経営破綻している。

この違いは何なのだろうか?  と考えてみると、要するに本物か偽物か?という事ではないだろうか?

考えてみれば大型レジャー施設で成功しているのはTDL位しか思いつかないわけで、 基本的に大都市圏でしか成立しないビジネスモデルだろう。 それをチマチマとした中途半端な規模で地方運営したとしても成功するハズがないように思える。 (地方公共団体と癒着している土建屋ならば、公共事業が増えて喜ぶだろうけど...)

だったら、ここ佐原の大祭とか、他にも真壁はひな祭りで地域活性化とか、 優れた地方文化を利用して町おこししているのが正しい方向性なわけ。 しかも、大規模レジャー施設と違って環境負荷も低いし、 単なる利潤目的の観光施設と違って、文化的背景、歴史的背景といった高い精神性も備えている。

時代のトレンドがエコな方向性になってきている今、真面目な話、お祭りってのも もっと見直されるべき貴重な文化遺産ではないのかねと思うわけである。

余談だけど、お祭りという意味では今度の新居は大当たりだ。 なぜって、引っ越し先の新居はなんと地元のお祭りのお囃子が聞こえる場所に建っていたのだ。

ある週末、自室でこの記事を書いていたところ、「ドン、ドン、ドン...ドドドドッン。」と 遠くから太鼓囃子が聞こえてきた。 もちろん、佐原の大祭のような大きな祭りではなく、小さな小さな地元のお祭りだけどね。

そして夜にはその方向から小規模ながら打ち上げ花火が... 「パァ〜、ヒュゥ〜、ドドン〜。」 自室で祭り気分が楽しめるとは、こりゃついてる。 この新居、安普請の貧乏人アパートだけど、意外にも結構当たりかもしれない。 (部屋の窓から筑波山の遠景が楽しめるし。)

☆BG/L、BG/Pの電力効率を考える。   
と言うわけで、余談から本題へ。CPUの省エネについて考えているわけだが、チップ間アクセスを減らすという意味では もう一台参考になる機種がある。BG/Lである。

性能面から見たBG/Lは得意分野・苦手分野の性能差が極端に大きいので、 当サイトの性能面での判断は用途によって極端に分かれる。

利点は、低コスト・低消費電力、そして高いスケーラビリティー。 LINPACKでの高性能は、このスケーラビリティーの寄与によるところが大きい思う。

逆に、欠点は適用範囲の狭さ。 特に、物量作戦が根本の設計思想なので、ノード数が極端に多い割にネットワークバンド幅が狭いのが最大の弱点である。

大雑把に言うとB/F比が低いアプリ(LINPACKやMDが代表例)や粒度が粗いアプリ(モンテカルロ法など)、 それにノード数に比例して問題規模を拡大できるアプリ(GTCの評価結果が典型例)では低コスト・高性能と思われる。 だが、高B/F比や細粒度のアプリ(CFD分野などが代表例)や、問題規模が最初から決まっていて高速に解こうとする場合などでは、 効率が大きく低下して潜在能力を発揮出来なくなる。 (世間の評価はLINPACK性能が良ければ全ジャンルで高性能という評価っぽいが、それは明白な誤りである。 LINPACKで高性能を得る事は名機の必要条件ではあるが、十分条件ではない。)

しかし、視点を変えて電力効率面から見ると、これは悪い設計ではないだろう。 実際、LINPACKのPOWER項目の評価では上位を独占しているのがBG/Lの後継機であるBG/Pである。

もちろん、LINPACKのPOWER項目で優秀な成績だったとしても、それはおそらく低B/F比ジャンルのみの成果であろう。 LINPACKがHPCの実際の性能を代表していないという批判があるが、 当サイトの判断ではLINPACKで見るPOWER項目も同様の批判を受けることになるとは思う。 だが、これらの機種がなぜ電力効率面で良い成績を出しているかは、考えてみる価値はあると思う。

BG/Pについてはシロウトが入手できるアーキテクチャの論文が見つからなかったので、BG/Lで考えてみよう。 BG/Lの特徴はいくつかあるが、当サイト的に見た場合はこんな感じではないだろうか?

ここで、なぜBG/Lが低消費電力であるのかを考えてみよう。

BG/Lの特徴はネットワークなどの装備をすべてチップ内に取り込んでいることにある。同様にノースブリッジも無い。 BG/LのノードはDRAM以外はほぼワンチップ構成であり、これは前回書いたワンチップ化という構成の理想型でもある。 チップ外アクセスはネットワークとDRAMへのアクセスがベースで、FSBのようなノースブリッジへのやり取りも無いし、 ネットワーク用チップへの外部アクセスも無い。 (ネットワークアクセスのための専用コアも無くて、ネットワークアクセスはチップ内の2つのプロセッサのうちの1つが直接処理する。)

おそらくこれは、ノードを複数チップで構成することによるチップ間アクセス増大という消費電力的デメリットから身を守るための措置であろう。 なんせ物量作戦が基本方針だから、ノードの消費電力は物量規模拡大以上に低消費電力的でないと、 物量作戦自体が自分で自分の首を絞める事になりかねないからだ。

また、ワンチップ化はノード単体を非常に小さくすることでワンボード化しコストを下げるという設計思想に基づくものと推測できる。 実際、BG/Lのノードはノードと言うよりはDIMMをちょっとでっかくしたような構造で、 高密度実装という意味では優れている。

もう一つはクロックを意図的に下げている点で、これはノードのB/F比低下を最小限に止めたいという意図と、 消費電力当たりの性能を高く維持したいという意図があると思われる。 元々が物量作戦ベースなのだから、これによる性能低下はその分だけノード数を増やせば良いという設計思想だろう。

要するに、チップ内部の設計は要求性能ベースではなく電力効率ベースで最適設計して、 チップ間アクセスはDRAMのようにオンチップに統合できないものに限るという発想である。 ネットワークはHPCである以上は装備することを避けられないが、 ネットワークバンド幅はコスト増大と消費電力増大を招くので、 ネットワークについてはレイテンシだけが問題になる用途に絞る作戦となっていると考えている。 高ネットワークバンド幅が必要な用途は最初から除外されて設計していると見るのが妥当である。 (ちなみに、この作戦は低B/F比用途に限ればかなり有効な戦術と思われる。)

つまり、消費電力を下げる目的がメインであれば、BG/Lから読み取れる省電力化のコツは下記の通りだろう。

ただし、この方法は決して万能ではないと思う。 たとえばBG/Lでは、下記の通り低消費電力化のために失ったものも多くある。 これらの問題点は、低消費電力化、低価格化のためにメモリとネットワークのバンド幅を簡略化した事と、 物量作戦によってノード数が極端に増えたことに起因する、いわば"低消費電力化の反動"である。 たとえば、ベクトル機では高い実効性能と高消費電力が同一起源の光と影の関係にある。 これと同様に、BG/Lでは低消費電力・低コストと狭い適用範囲が同一起源の光と影の関係なのだ。

では、これをPC用途に適用する事を考えてみよう。

PC用途ではHPC用途ほど用途が限定できなから、ある種の冗長性はHPC用途よりも大きくなり、 無駄な回路が増えることはある程度はやむを得ないと思う。 なぜならば、PC用途ではコントローラ的な使い方が占める割合がHPC用途よりも格段に大きいからだ。 実際、HPC用途に汎用CPUを転用する場合にはダイ面積に対して浮動小数点演算ユニットの面積が 小さすぎる問題点がNCARのレジュメで指摘されているが、これは逆に言えばPC用途では 浮動小数点演算以外の負荷が占める割合が大きいことの証拠でもある。

しかし、ある程度の冗長性を認めなくてはならないとしても、 クロック周波数をアーキテクチャに合わせて調整する事と、チップ間アクセスを抑制するためにワンチップ化する事は可能であろう。 そもそも、最近のPC用CPUでのマルチコア化はダイ内部での使用可能トランジスタ数が増えたことが背景にある。 マルチコア化にトランジスタを投入するのはアプリ側からの利用が難しく、 用途がPCの場合は現状のアプリケーション環境では最適な判断ではないと明白に言い切ることが出来る。 データ供給さえ間に合えば演算ユニットがあるだけ助かるHPC用途とは事情が異なるのだ。 つまり、マルチコアに回すトランジスタをネットワークやサウスブリッジに回せばよいだけの話である。

あと、このことからもう一点省エネ対策が見えてくる。 それは、3次元ダイスタッキングだ。

ダイスタッキングとは外部との接続ピン数がバンド幅のボトルネックになるのを避けるために 貫通ビアを使ってダイとダイを3次元的に直接貼り合わせる技術の事。 この技術を使えばダイとダイを高い伝送レートで結びつける事が出来るらしい。 DRAMはCPUとは半導体製造プロセスが全然違うので、 ムーアの法則がトレンドライン通りに順調に伸びたとしても 何らかのブレークスルーが無い限りオンチップ統合は当面できそうもない。 その結果、ダイスタッキングによる接続には大きな期待が寄せられている。

で、チップ間接続を減らすという意味ではどうだろうか?

貫通ビアはシリコンウエハの厚み分だけの伝送距離なので、従来のプリント基板による場合よりも 格段に伝送距離が短くなる。従ってドライバ回路を大幅に簡略化できる事となり、 伝送レートの問題だけではなく消費電力的にも大きな省エネが期待できることになる。 つまり、CPUとDRAMがダイスタッキング可能になれば、性能だけではなく省エネ性も格段に向上する理屈になる。

PC用CPUの場合はコスト(歩留まり)という問題点があるので、 ただちにダイスタッキングへと舵を切れるかというとさすがに無理だろう。 しかし、HPC用途ではこちらの方向も十分に考えられるらしい。

ずいぶん以前になるが、当サイトではベクトル機のバンド幅不足解消にはメモリアクセスの光化が将来の方向性だと予想したことがある。 ベクトル機のB/F比低下抑制策として、まずシリアル伝送化を行うべきであり、最終的には光化が理想であると予想していた。 この予想は今のところではズバリ的中していて、NECのSXシリーズに関してはESの頃はパラレル伝送だったのが現在ではシリアル伝送となっており、 また、現在研究中のアクセス方式は光伝送ベースだそうだ。

だが、貫通ビアによる3次元スタックの場合は、レーザーによる光伝送と異なり、 省エネ性という意味で別のメリットがある。光伝送では電気信号を光信号に変換する際にどうしても原理上のエネルギーロスが 発生してしまうので、電力効率という意味まで考えれば一長一短とも言える。 (ただし、光伝送はエネルギーロスの距離依存性が小さいので、伝送距離が長い場合は逆に有利。) 3次元スタック技術のメリットはバンド幅面のみが強調されている嫌いがあるが、消費電力面からも注目株であろう。 省エネ性が強く要求される用途ならば、光接続化よりもベストソリューションになりうると思われる。 (もっとも、3次元スタッキングではDRAMチップがCPUの高熱に直接晒されるというデメリットがあり、こちらも万能ではないから総合判断は難しい。)

ベクトル機での膨大なバンク数分だけDRAMチップをスタック出来るか?という問題点があるものの、 もし3次元スタッキングでDRAMを3次元統合出来ればベクトル機の消費電力は大幅に低減する事が出来るだろう。 現状ではベクトル機がBG/L的な省エネ手法を取り込むことは不可能だが、将来的には可能になるかもしれない。1)

☆GPGPUの適合用途とネットワークアクセス。   
これに関して、もう2点だけ追加しておきたい事がある。 それはGPGPUとネットワークアクセスの消費電力問題だ。

GPGPUは最近の注目株であり、高い演算性能が注目を浴びている。 この記事を読んだりすると まだまだプログラミング上の問題点が大きそうではあるが、 そもそもこのように注目を浴びること自体が以前はなかった。

当サイトのGPGPUへの着目点は、COTSプロセッサとしてはほぼ唯一B/F比が高い事であって、 理論ピーク性能が高い事は二次的なメリットと考えていた。 では、なぜそのように考えたのか?

たとえば、GPGPUをスカラ機とベクトル機に分けて強制的に分類するとすれば、 どちらに近い存在だろうか?

GPGPUには内部に小型のスカラプロセッサを並べたものもあるから、 GPUによってベクトルだったりスカラだったりという意見が出る事が予想される。 しかし、当サイトではシェーダの設計よりもキャッシュベース・非キャッシュベースの差を 重要視する2)ので、シェーダ構成の違いによらずベクトル的な存在と考えている。 当サイトの考えでは、GPGPUはキャッシュベース・アーキテクチャではないという理由においてベクトル機寄りなのだ。

これを消費電力面から考えてみよう。 キャッシュベース・アーキテクチャではないということは、 つまり、高い演算性能を実現するためには高いメモリアクセス(チップ外アクセス)が頻発する事を意味する。 それが意味するものは高消費電力化である。

つまり、GPGPUはたとえ理論ピーク性能が高くてもLINPACKのようなローカリティーの高いアプリで使うのは 電力効率面からは不適だと指摘できる。 結局、この点ではベクトル機と同じ状況であり、キャッシュが効かない用途でないと 電力効率面ではキャッシュベース・アーキテクチャに負けることになりかねない。

と言うわけで、当サイトはGPGPUについて高理論ピーク性能よりも高B/F比に着目している訳である。 単純に理論ピーク性能の高さだけに注目するのは短絡的であり、 ベクトル機同様に流体分野の方がGPGPUのメリットは生かしやすいだろう。 (GPGPU間でのデータアクセスをどう解決するかという問題点は残されているが...)

もう一点はネットワークの消費電力である。

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

前回、当サイトはこの図を示して高B/F比領域ではベクトル機とスカラ機の電力効率にはあまり差がないだろうという 推測を掲載した。しかし、上記の実験事実は約2倍の差でベクトル機が有利な電力効率になっている。

前回の理屈では、同一の電力効率にはなってもベクトル機優位になる理由はない。 と言うわけで、スカラ機ではメモリアクセスに伴うドライバ回路の消費電力の他に何かが電力を消費している事になる。

それは何だろうか?と考えてみると、考えられるのはネットワークの消費電力だろう。 スカラ機の場合は低い効率と低い性能をノード数で稼いで補っている。(低コストだからこの戦法が可能になる。) その結果、ベクトル機に比べるとシステム全体でのネットワーク通信の比率が高くなる事になる。 つまり、ネットワークでの消費電力がベクトル機より増える理屈である。 LINPACKのような用途ではそもそもネットワークアクセスの比率が低いので問題が目立たないが、 B/F比が高いアプリでは顕著に問題化するだろう。

ちょっと考えてみればわかるけれど、バンド幅当たりの消費電力は必然的に メモリアクセスよりネットワークアクセスの方が大きくなる。 (ネットワークの方が想定通信距離が長いし、冗長性も大きい。) キャッシュで出来る事をメモリアクセスでやろうとすると電力効率が悪くなるのと同様な理由で、 メモリアクセスで出来る事をネットワークアクセスでやろうとすると電力効率が悪くなるのである。 その結果、ベクトル機ではメモリアクセスで済む所をスカラ機ではネットワークでやり取りするという筋の悪い構成となるので、 上表のように電力効率が2倍も悪いのであろう。

この辺りは、キャッシュで済む所をメモリアクセスでやっているベクトル機が低B/F用途で電力効率的に不利なのとは 逆の事情であり、とても興味深い。

☆CELLの電力効率を考える。   
さて、では次にCELLの電力効率について考えてみたい。 実はこれには既にプロによる論文が出ている。 以前、「CELLの相対評価と絶対評価」を自己評価する。 というコラムで紹介した論文がそれである。

この論文によればCELLの電力効率は恐ろしく高い。 実際、CELLを使ったスパコンであるQS22は488 Mflop/s/Wattの性能を達成している。 以前のコラムで紹介したとおり、メモリのバンド幅が問題にならない LINPACKではCELLの潜在能力は遺憾なく発揮されるだろう。 (GEMMの倍精度版であるDGEMMがLINPACKでは全負荷中で圧倒的な割合を占める。)

その割に、Roadrunnerの効率は悪くて74.6%しかなく、 効率が高いことで知られるLINPACKとしては合格点をあげられない数値なのがちょっと疑問である。 だが、おそらくこれはCELL自身の問題ではなく、複雑なネットワークと、それによる実質的なネットワーク性能の低下 というシステム設計上の問題によりメリットが薄められているためと思われる。 (ノード内の性能だけならば非常に高い効率だと当サイトでは推測している。)

当サイト的にはCELLはスパコン用途では非常に注目であり、 「CELLの相対評価と絶対評価」を自己評価する。で書いたとおり、 その性能はHPC分野で高い性能を発揮出来るものであると思っている。 今のところ倍精度演算強化タイプへの進化だが、当サイト的にはバンド幅強化タイプの出現により、 さらに苦手分野の少ないマシンが構築されるであろうと、強く指摘しておきたい。

さて、ではなぜCELLはこのように電力効率が良いのであろうか?

一つ指摘できることは、SPEの能力がバンド幅に対して高すぎる点が逆に低消費電力化に寄与している点が考えられる。 LINPACKではメモリのバンド幅はある程度低くても問題なく、一定値以上に大きくても性能向上にはほとんど寄与しない。 その結果CELLの超低B/F比がLINPACKでは性能低下に結びつかないわけだ。 ベクトル機の場合とは逆に、低B/F比である事がLINPACKでのPOWER項目では有利に働いていると指摘できる。

RAMBUSのTBI(3)という記事によると、 RAMBUS社のSteven Woo博士によれば下記の通りだそうだ。 「別の視点から見てみよう。今の時点でも、Processorには十分なメモリ帯域は供給できていない。 通常演算を行うためには、1Bytes/flops以上の帯域が必要になってくる。 例えばCell BEの場合、数百Gflopsの演算性能を持っている。 ところが、メモリ帯域は25GB/sec、比率にして1:10のオーダーでしかない。 もっと帯域があれば、Cellはもっと高速に動作できることになる。 他の汎用Processorでも、たとえばIntelのProcessorは常に帯域不足に悩まされている。 もしこれがもっと大きな帯域を利用できれば、更に性能を上げることができるだろう。TBIはこうした部分にも役立つことになる。」

この意見は当サイトがCELL発表直後に書いたCELLの相対評価と絶対評価というコラムの内容と完全に一致する見解だ。 Steven Woo博士は当サイトとものの見方が似ているらしい。(その筋のプロと同一意見なのはちょっと嬉しい。) ともあれ、LINPACKは比率にして1:10のオーダーでしかない細いメモリバンド幅でもバンド幅がボトルネックにならないわけで、 その結果、性能低下を起こすこと無く低バンド幅が消費電力を抑えているので電力効率が非常に良いというわけだ。

だが、ちょっと皮肉なこの結論とは別に、本当の意味でCELLの低消費電力を支えている技術があると思う。 それは、ローカリティーをキャッシュではなくLSで利用している点だ。

当サイトでは、ノータリン解消のためこのお正月にプロの論文をいくつか読んだ。 その一つに Scientific Application Performance on Candidate PetaScale Platformsという論文がある。 これはスカラ機の優劣をHPCジャンルのペタスケールアプリで評価するという論文で、内容はとても興味深い。 興味のある方はご一読いただきたい。 その中で、スカラプロセッサの優劣を決める重要要素として以下の2点が指摘されていたことが興味深かった。

当サイトが指摘しておきたいのは、この項目はいずれもメモリに関する評価項目であるという点だ。 で、ここでバンド幅については前回考えたので、プリフェッチについて考えてみよう。

なぜ、プリフェッチに優れているプロセッサがHPC用途では重要なのか?  それは、プリフェッチ機能が優れていないとHPC用途ではキャッシュが上手く機能しないからだと思われる。 (というか、論文ではそういう意味のことが書いてある。)

キャッシュは一度利用されたデータや命令は近いうちに再利用される可能性が高いという原理と、 一度利用されたデータの前後のデータや命令はほぼ同時に利用される可能性が高いという原理を用いている。 このため、本来ならばキャッシュは何もしないでも勝手にアプリケーションを高速にしてくれるありがたい機能である。 いわゆる"ただメシ"という奴で、本来ならばキャッシュは明示的な利用を求めない。

しかし、HPC用途では事情が異なる。 問題なのは、取り扱いデータ量がPC用途とは比較にならない位大きいので、 放っておいたらキャッシュ中のデータが再利用される頃にはデータが追い出されている可能性が高い点だ。 このため、プリフェッチ機能を利用して明示的にキャッシュ内にデータを取り込む必要性がある。

キャッシュに頼らないベクトル機は例外だが、 スカラ機の場合はプリフェッチなど明示的な利用を通じてキャッシュをいかに有効利用出来るかどうかが、 演算効率を決めていると言っても過言ではないだろう。 少なくとも、PC用途のようにキャッシュ任せに放っておいて高速化できるような単純な話ではないのは確かだ。

プリフェッチが機能しない場合は、データアクセス毎に主記憶を直接読みに行く事になり、 つまりはレイテンシ分だけの性能低下が発生する事になる。 当サイトはスパコンの教科書でスカラ機にベクトル機用のアプリを単純に適用した場合、 効率が1%以下になる例が示されていたのを見たことがある。 これを当サイト流に単純に解釈した場合、その効率は"メモリのレイテンシ分の1"になっているハズであり、 現代CPUのメモリレイテンシは数百程度なので、1%以下という効率とほぼ符合する。

余談だが、プリフェッチなどを駆使してキャッシュにヒットするように工夫してスカラ機向けの最適化をした場合では 効率は約20%になったそうだ。この場合の効率は当サイトの超トリ頭単純推定では "ハードウエアのB/F比/ソフトウエアのB/F比"で決まっていると思われる。 アプリのB/F比が教科書に載っていないのでこのオーダー分析が正しいかどうかは不明だが、 少なくとも非合理な値ではないようだ。

話を戻すけれど、当サイトはスパコンを使うような高度な仕事はしたことがないが、想像するにおそらくは プリフェッチ機能を利用しないでも高性能が出せるHPC用アプリケーションはほとんど存在しないのではないだろうか?

とするとどうだろうか?

キャッシュベース・アーキテクチャでは、まずプリフェッチでデータを取り込んだ上で、 プリフェッチしたデータはキャッシュ上に存在する事が明白なのに タグを参照してキャッシュアクセスするべきかどうか判断するという2度手間をしている事になる。 最大の問題点はアクセスが行われるたびにタグが参照される事になり、 参照回数だけ無駄な電力が発生することであろう。 (その意味ではレジスタ数が多い方が助かる場合が多いだろう。その点でx86はHPC用途では不利。)

つまり、明示的にしか利用できなくなった段階でキャッシュはLSよりも非効率なアクセスとなるだろう。 その意味でCELLのLSの有効性が大きくクローズアップされるわけだ。

LSでは基本的には明示的なロード・ストアしか行われない。 これは、RISCプロセッサのLOAD/STOREアーキテクチャのローカルメモリ版とも言えるかもしれない。 その結果、2度手間な消費電力が大きく削減される事になる。 また、タグ周りの無駄な回路も削減できて、これも省エネに貢献している事になる。

要するに、プリフェッチ機能を上手く利用しないと性能が発揮出来なくなった時点で、 キャッシュ周りの複雑な回路構成は電力効率的にペイしないものになっていると考えるべきだろう。 だったら、単純なメモリの延長線上として明示的にアドレスを振ってやればいいわけで、 これがCELLのメモリ周りの電力効率を上げている主因であると考えている。 要するにロード・ストア周りのアクセスがすっきりと整理されていて無駄がないわけだ。 (ただし、これに合ったプログラミングモデルを確立するのには時間がかかるので、 現段階ではプログラマに高いスキルが必要になるという欠点があるけど。)

と言うわけで、プログラミング・スキルの問題点はあるけれど、 長期的に見ればキャッシュよりLSが省エネ的にはお勧めだと言うのが、当サイトの今回の結論。 (ちなみに、今回のネタではないので説明は省くけど、性能的にもお勧めだと思う。) 上記の通りHPC用途では特にそうで、長期的に見た場合、 おそらくはHPC用途ではキャッシュベース・アーキテクチャの不適合性が今後さらに問題視されていくと思われる。2) なぜならば、長期的にはスカラ機のB/F比は低下傾向にあることは間違いないからだ。 (NehalemではQPIによって一旦は上がるけど。)

ただ、CELLがこのようにLSが効く用途ではキャッシュベースアーキテクチャよりもさらに省エネだったとしても、 これをx86に応用するのは非常に困難なのが残念だ。 たとえば、intelのLarrabeeなんかでは互換性を考えなくても良いのでいろいろな検討が出来うる。 しかし、x86-CPUでこれをやったら完全にアウトだ。なぜならば、LSを搭載したが最後、過去のアプリとの互換性が無くなってしまうからだ。 これはx86-CPUでは万に一つも許されない方向性であり、ハードウエア直接の場合はもちろんのこと、 ソフトウエアで互換性を取るプロセッサを含めてでさえ実質上すべてのプロセッサが敗退しているのは歴史が証明している。 Alpha、Crusor...3)

と言うわけで... PS3を見てわかるとおりCELLは確かに高消費電力である。 しかし、電力消費以上に性能が高く、またそれはLSというキャッシュよりも低消費電力・高効率な ローカリティー利用という技術的背景があって成し遂げられていると見るべきであろう。

本来CELLはSONY・東芝・IBMの合作プロセッサである。 従って、日本発の技術として日本製スパコンにCELLが採用されても良いはずなのに、 Roadrunnerによってあたかもアメリカ単独の技術のように扱われてしまっている。 正直な話、せっかく日米共同で研究開発したのに、なんだかもったいないなぁ〜という気がするのは 当サイトだけでは無いのではないだろうか?

☆未来の低消費電力チップとは?   
というわけで、話を戻すけれど、内部アーキテクチャ的な省エネや製造プロセス的な省エネ以外の観点から、 チップ間アクセス削減というちょっと変わった切り口でエコな省エネチップについて考えてみた。

その結果、当サイトの理想型とは、すべてのチップをワンチップ化し DRAM以外のチップ外アクセスを無くしたチップとなる。 また、3次元ダイスタッキングによりDRAMとCPUを疑似ワンチップ化出来ればさらに良いだろう。

CPUとDRAMが貫通ビアで接続できれば、省エネ効果だけではなくバンド幅の激増により性能も上がる。 また、その分2次キャッシュ容量を大きく減らす事が出来るのでさらに省エネになるし、 その結果、発熱が減ってさらにスタックに有利になる。(DRAMは高温に弱い。)つまり、 DRAMの3次元ダイスタッキング品だと、ローエンド製品ならば2次キャッシュは完全に省略できるかもしれない。

もちろん、メモリの増設は可能である必要性があるからメモリインターフェイスは必要だが、 本来DRAMは最低限のメモリ粒度分は装着必須であるのだからその分だけはスタックしても製品ポジションが変わることはないだろう。 つまり、最低限の容量をスタックし増設用のメモリインターフェイスを備える製品という事になる。

なんか我ながら夢物語風になってしまったけど、当サイトが自分の論理に従って考えた理想像とはこのようなものである。 当サイトの新たな長期予想という事で、当たるも八卦当たらぬも八卦...ってな感じでワッチしていきたいと思う。

なお、この3連休明けから1週間ほど出張となり、出張先に自前ノートPCを持ち込めない関係でご感想メール等の返信はしばらく出来ません。 あしからずご了承ください。



1)
もし、すべてのDRAMチップをスタックする事が技術的に困難ならば、 CELLのLSのようにメモリの一部をLS的に統合する手法も考えられる。 この場合はローカリティーが低いアプリでは省エネ性は向上しないが、 ローカリティーが活用できる用途では省エネ性が格段に向上するだろう。 つまり、高B/F比アプリでの高効率はそのままに、 低B/F比アプリでの省エネ性をスカラ機に近いレベルまで解決出来るのでは無いだろうか?

2)
余談だけど、当サイトも周りの影響を受けてベクトル機とスカラ機なんて書き方をしたりする。 しかし、スカラ機がHPC用途に不向きというよりは、 より正確にはキャッシュベースアーキテクチャが不向きと言い換えた方が正確だろう。 キャッシュベースアーキテクチャではないスカラプロセッサ、すなわちCELLとか、一部のGPGPUとかは 科学技術計算に結構向いているわけだから。

3)
と、ここまで書いてきたら、牧野先生のWebサイトが更新された。 GRAPE-DR の現状 という記事がそれである。

同記事によると、「とはいえ、まあ、現時点では GRAPE-DR は1チップで実測性能で DGEMM 世界最高速を実現したわけで、 まあ、数千億掛けたという話もある Cell とかに比べてもピーク性能、実効性能、電力当り性能のどれも高い、 というところで結構悪くないものができたのではないかと思っています。 」だそうである。

この話、読んだのは7/19なんで当サイトの認識はまだまとまっていないが、直感的に見て おもしろいのはGRAPE-DRもキャッシュベースアーキテクチャではなくローカルメモリを使用してるという点でCELLと似ていることだ。 特に、データのローカリティーがさらに高い事を前提に設計している傾向が強いと思える構成である。 その結果、GRAPE-DRはCELL以上にデータのローカリティーに効率が左右される設計と思われ、 電力効率でCELLに勝っているという主張は、MD、粒子コード(銀河形成等)といったローカリティーの高い分野に関しては信憑性があると思われる。

ちなみに、その昔当サイトは牧野先生とはWeb上で論戦をしたことがあるのでGRAPE-DR計画に否定的見解と読者に思われている節があるが、 ここのMDGRAPE-2の項で紹介したとおり、本来GRAPEシリーズに対する当サイトの評価は悪いものではない。 世間は広いのでGRAPE-DR計画をゴミクズ扱いしているブログも存在するけれど、 当サイトにはこの手の評価は残念ながら「結論先にありき。」に思える。