CPUの省エネ、前編(ベクトル機を参考に考える。)   

2008年7月6日



☆チャリンコ通勤がピンチ。注:いつもの三日坊主ではありませぬ。   
最近、テレビでも地球温暖化の番組が増えてきた。 真面目な番組は視聴率が悪いのであまり話題になる事はないのだけど、 NHKの日曜特番以外の番組でも地球温暖化関連の番組を多く見かけるようになった。 最近の報道はちょっと過熱気味で、一過性のブームで終わったりしないかと少々心配になるが、 悪いことではない。

と言うわけで、当サイトもちょっとだけ地球温暖化対策を始めた。 晴れた日にはチャリンコ通勤である。1)

晴れた日に車通勤の時より30分ほど早めに家を出れば 田舎道にはアジサイとかアザミとかが咲いていてきれいだし、 田んぼの中に一部休耕田となっている場所があって葦が茂っているのだが、 そこからオオヨシキリのさえずりが聞こえてくる。 これからは、ねむの木がきれいな季節で、こちらは今後が楽しみ。 なんかいかにも日本の初夏という感じで、いいね。

あぁ、仕事なんてオラ知らね...なんて、通勤を忘れてそのまま海までサイクリングに出かけてしまいたい!

チャリンコ通勤だと田んぼのあぜ道でオオヨシキリのさえずりが楽しめるのだ。
ちなみに、オオヨシキリはウグイスと同じで、「声はすれども姿は見えず。」の典型。写真は撮ったけど、姿は映っていなかった。
さすがに鳴き声の録音まではできないので、オオヨシキリの鳴き声はこちらでどうぞ。

だが、この自転車通勤が今ピンチなのだ。 いつもの三日坊主...と言うわけではないのに、最近はほとんど自転車通勤をやっていない。

それはなぜか?

梅雨という事情もあるのだが、実は知り合いに「通勤手当の詐欺になる可能性がある。」 と指摘された事が原因である。当サイトが自転車で会社に通う前には自動車通勤だったが、 言われてみれば自動車通勤手当の申請を撤回したわけではない。

しかし、だからといって自動車通勤手当の申請を止めてしまったら、 この梅雨時だから結構な頻度でガソリン代自腹となってしまう。 ここ数ヶ月のガソリン代高騰を考えれば相当な痛手となるし、 もし2年前の激務が復活するようなことがあれば自転車で午前様帰宅になってしまうしね。

う〜ん、なんか良い方法はないかね〜。なんて考えていたら、ちょっと良いアイディアが... これは皆さんの利害関係がすべて丸く収まる方法である。 通勤手当半額にする代わりに自転車通勤でもOKに規約を改正すればいいのだ。

なぜならば、まず、企業は通勤手当の出費が半分ですむ計算だ。 従来通り自転車通勤を通勤手当詐欺状態にしておくと、自転車通勤する人は当然居なくなる。 つまり、自転車通勤者から通勤手当を全額回収しようとすると、逆に全員が自動車通勤復帰となって 1円も戻ってこない。これを考えれば実は半額手当で済むのは大幅な経費削減になる。

その上、通常は通勤手当を削減すれば全社員から大ブーイングだが、 この場合は削減しても社員の自発的申告ベースだから不満が出ない。 おまけに、「弊社は地球環境に配慮して社員の自転車通勤を促進する社則を整備しました。」とアピールできる。

我々も大歓迎だ。まず、メタボが減って健康になるし、地球温暖化対策が進んで精神的満足感も得られる。 半額支給となるとせめて元を取ろうと最低限でも勤務日の半分は自転車通勤しようとするので三日坊主になりにくくなる。 しかも月の半分以上を自転車通勤できれば、差額は合法的に懐入りである。 当然、合法的お小遣い稼ぎの手段としてやる気アップ。 「今月は全出勤日チャリンコ通勤にして通勤手当で飲み会じゃぁ〜。」と頑張るだろう。

そして、実はお国にとってもありがたい話である。 メタボが減れば生活習慣病患者が減って医療費削減になるし、 「国民全体で温暖化対策やってます。」と明日から開催される洞爺湖サミットで日本の姿勢をアピールできる。 地球温暖化予測の分野ではIPCCで世界をリードした日本だが、 温暖化対策の実行面では産業界の反発により情けないことに環境後進国となってしまった日本。 だけど、これならサミット議長国としてのメンツも保つことができるだろう。

雨天の通勤に備える必要性があるので、これで自動車が売れなくなる訳ではないだろうし、 逆に自転車業界は潤う。これで困るのはガソリン業界位のものであろう。

どうだろうか? チャリンコ通勤でも通勤手当半額支給制度... ガソリン業界以外は、本人も会社も国もすべて丸く収まる結構いいアイディアだと思うんだけどなぁ。

☆CPUの消費電力問題について考える。   
さて、と言うわけで今回は地球環境を考えて...というわけでもないのだけど、省エネ問題に関しての話題。 CPUの消費電力について考えてみた。

いろいろな報道を読んでいると、今CPUアーキテクチャの方向性が絶対性能から電力効率に移行しつつある事を感じている。 これにはいくつかの理由が考えられるが、下記に示したいろいろな要求事項の複合的な要因が絡み合った結果だと思っている。

要因の一つ目は、単一コアの性能向上を無理矢理行おうとすると消費電力が激増するらしいという事。 パターソン先生が言う3つのウオールの内の「パワーウオール」というわけだ。これは 要するに性能アップに対するトランジスタ効率が最近はポラックの法則よりも下がり気味である事を意味しているというのが当サイトの認識。

二つ目は、データセンターなどでサーバー用CPUに関して消費電力削減が求められるようになったこと。 サーバー用CPUでは昔は信頼性とスループットさえ高ければOKみたいな感じだったのだが、 最近ではデータセンターでの消費電力問題が大きな課題として浮上してきている。 このため単にスループットが高いだけでは合格点にはならず、このジャンルのCPUには 消費電力当たりの性能が高い事が求められるようになってきている。

三つ目は単一コア性能が上げられなくなったことに対する言い訳としての電力効率向上という政策上の理由付け。 単純なマルチコア化の進行は、PC用途では潜在能力を生かし切れないセンスの悪い性能向上手法である。 しかし、単一コア能力の向上はILPウオールの存在により思うに任せない。 そこで、単一コア性能の向上は電力効率面からあきらめて性能向上はマルチコア化で行うという、 マルチコア化の方向性を正当化する言い訳として電力効率が取り上げられているという側面があると思う。

とまぁ、十分に正当性のある理由からほとんど言い訳に近いものまでいろいろな理由があるけれど、 ひたすら性能向上を追い続けてきたチップから省エネルギーなチップへと時代の流れが移ってきているのは事実であろう。

現段階では省エネという意味で一番進歩しているのはPC用途ならばAtomだと思う。 消費電力が小さいという事は言うまでもないが、当サイトが指摘したいのはダイサイズが小さいと言うことだ。 ダイサイズが小さいと言うことは製造時の消費エネルギーがCPU1個当たりでは小さくなる事を意味するからだ。 実はパソコン製造時の消費エネルギーと言うのは意外に大きくて、CPU単体ではなくパソコン全体としてだが、 一説ではパソコンが製品寿命までに消費するエネルギーとパソコン製造時に消費するエネルギーは、ほぼ同じレベルだそうだ。 (←情報ソース:放送大学の授業より。)

量がたくさん出ているという意味ではCore MAの省電力性も重要な地位を占める。 いくら省エネチップでもシェアが小さければ炭酸ガスの総削減量は小さいままだからね。 もちろん、省エネチップとしてはVIAの技術力はよく知られている。 従って、今後出てくるチップとしてはおそらくIsaiahが相当に有望だとは思う。 残念ながらまだ出荷されていないから確かめようがないけれど...

そして、ゲーム用CPUまで用途を拡大すれば...誰も信じていただけないと思うが... 実はCELLが一番省エネチップだと当サイトでは考えている。 えぇ〜、と思う方...電力喰いのPS3を思い浮かべれば、まぁ驚かれて当然ですけどね。

理由は後編で説明するけれど、当サイトの判断基準が絶対電力の小ささではなく、 電力効率の良さなので、省エネ性の悪さを絶対性能の高さが上回れば評点が上がるため、 こういう一見珍妙な判断が出てくるのである。

☆現状の省エネCPU。(intel、頑張ってる。)   
CPUの現状の省エネ手法という意味では現段階ではintelが結構頑張っていると思う。 偉いのは世の中がまだ絶対性能評価の全盛期に、 単にCrusoe対抗という意味を超えて省エネチップの開発に力を入れていた事である。 (Core MAの祖先であるBaniasが世に出てきたとき、時代は絶対性能による評価の全盛期。 Net-Burstに代表される高クロックCPUがもてはやされた時代でもある。)

当時、飛び抜けた省エネ性能を誇っていたCrusoeに対抗してBaniasは生み出された。 だからノート用CPUとして省エネ性能第一なのは当然である。だが、 Baniasの偉いところは性能をそれほど犠牲にしなかった事である。 絶対性能面でも総合的に見ればNet-Burstにちょっと負ける程度の性能低下で済んだからだ。

結果、Baniasの子孫はNet-Burstの失敗という苦境からintelを救うわけだが、 そういう経緯からintelは現代に至るまで省エネ性能をデスクトップCPUからも排除する事がなかった。 Net-Burst時代はintel製CPUが電力喰いでAMDが省エネと言われたものだが、今や立場は180°入れ替わってしまった。 開発リソース2倍で複数の開発プロジェクトを併走できるという余力の差こそ背景にあるものの、 アーキテクトに先見の明があった証拠である。

また、プロセス技術に頼らない省エネという意味でも進んでいる。 出現当時Core MAは通常プロセスで作られているにも関わらずSOIプロセスで製造されているAMDより電力効率が良かった。 当サイトは開発年次の差違を考えればCore MAの性能面でのアドバンテージは世間の評価ほどAMDと差はないと考えているが、 省エネ性能という意味では大きなアドバンテージを持っていると考えている。

そして、別系統ながらその流れを受け継いでさらに進化したのがAtom。 Atomは思い切ってOut-of-Orderを捨て、その性能低下を高クロック化でカバーしている。 (高クロック化は省エネ観点からはダメだというのがPCマニアの主流意見だけど、 このように慎重に設計すれば高クロック主義も決して死んではいないのだ。)

余談だが、当サイトはAtomを購入予定にしていて、マザーがもう少し潤沢に出回るようになれば購入に踏み切る予定。 そのために、引っ越しのため必要になった洗濯機と冷蔵庫の購入を別にすれば、今のところボーナスには一切手を付けないでいる。 (実は無音キーボード購入のために秋葉に言った際にAtomマザーも探したのであるが、 なんせ入荷量が少ない上に人気商品だから売り切れだったのだ。トホホ。)

というわけで、intelの省エネプロセッサを俯瞰するとそれが回路設計技術に頼る事が多いことが見えてくる。 省エネ設計というといくつかの手法が考えられるが、当サイトの見るところによればintelは プロセス技術などよりも回路設計技術で省エネを達成している部分が大きいように思う。

要するに、動作していない回路のクロックを落としたり電源を切ったり、 キャッシュからデータを追い出した上で電源を落とすというスリープモードの強化などが典型例だ。 動いていない回路の電源を落とすというのは、 家庭での省エネで言ったら「使っていない部屋の電気は切りましょう。」的な考え方である。

また、Atomの流れは回路設計でもよりマクロな観点から省エネを目指している。 つまり、Out-of-Orderの不採用という思い切った視座の転換である。 これは、つまり家庭の省エネで言ったら「電球よりも蛍光灯が動作原理的に効率が良いですよ。」的な考え方だ。

どちらにせよ、今しばらくはこのような観点から省エネ指向のCPUが開発されていくと思う。

☆ベクトルプロセッサはなぜ消費電力が大きいのか?   
では、CPUの省エネはこれ以外の観点からは達成できないのか?

そうではないと思う。 これを考える上で参考になるのは、スパコンの世界のベクトルプロセッサ。 ベクトルプロセッサは高性能、高効率と非常に優秀なマシンだが、 数少ない欠点として高価格と高消費電力が指摘できる。 というわけで、ここでベクトルプロセッサの消費電力について考えてみよう。

たとえばTOP500のリストにPOWERの項目が付け加えられたように、HPC分野でも省エネ性能が求められている。 名機として知られる地球シミュレータだが、数少ない弱点として電力を多く消費する事は 当サイトも過去のコラムで書いたことがある。 当サイトとは逆にベクトル機の評価が悪い方々が指摘する問題点も、多くが価格と消費電力である。

しかし、ではなぜベクトル機は消費電力が大きいのか?という問題点の根本に踏み込んで 説明してくれているプロの記事を探したのだが、これはと言うのが見つからない。 消費電力過多と批判するのは簡単だけど、ではなぜ消費電力が大きいのか?

たとえば、intelのようにチップ内部で使っていない回路を時に応じてスリープさせれば消費電力は 下がるのであろうか?

もちろん若干の効果はあると思うが、根本的な対策にはならないと思う。 スパコン分野の場合は浮動小数点演算という根本的な使用目的があって、PC用CPUを転用した場合、 使う回路は延々と使われるし使われない回路はずっと使われないだろう。 スカラ機の場合は他分野用のCPUをHPC用途に転用している訳だからHPC以外で使われる回路を止める効果が考えられるが、 科学技術計算専用機であるベクトル機の場合はそもそも使われない回路は最初から省いて設計しているハズである。 (たとえば、複雑な条件分岐命令に代表されるフローコントロール系の整数演算命令などはx86よりも簡易になっていると思われる。)

つまり、現在のintel的な省エネ技術で劣っているために高消費電力になっている訳ではないだろう。

では、x86-CPUで問題になっているデコーダーの消費電力はどうだろうか?

これも理由としては考えられない理屈である。 なぜならば、科学技術計算用途ではベクトル演算命令はデコード面での効率が非常に高いからだ。

ベクトル演算の本質は科学技術計算で演算量の大半を占めるループ演算処理をいかに高速化するかという点に現れている。 つまり、ベクトル演算の本質の一つにファーストループをベクトル演算命令で一気にカバーしている点に特徴があると指摘できる。 命令のデコードという意味では、ループ処理の中身で1命令毎にデコードを行っているスカラ演算の方が逆に非効率的と指摘できるわけで、 この部分がベクトル機の高消費電力の原因では無いだろう。

たとえばCore MAのアーキテクチャにおいてNehalemのLSDを考えてみると良い。 PenrynまでのアーキテクチャではLSDはデコーダーの前にある。 つまり、ループ処理があるとループの回数だけ命令が都度デコードされ、 そのための消費電力がループ回数だけ消費される。

しかし、Nehalemではどうだろうか?

NehalemではLSDがデコーダーの後にあるため、ループ処理ではデコーダーの消費電力が大幅に削減できる。 科学技術計算ではループ処理はほとんどの場合でコードのホットスポットとなるため、 この手法はPC用途よりもむしろ科学技術計算で大きな効果が期待できるだろう。

ではここでベクトル演算命令を考えてみよう。

ベクトル演算命令ではそもそも命令セット自体が1命令でファーストループをカバーすることを前提にISAが組まれている。 ループ処理の高速化をISAレベルでカバーするのがベクトル機の本質の一つである。 これは、とある読者のお一人から指摘された事なのであるが、 NehalemのLSDをさらに根源的な意味で自然に実装しているのがベクトル機であるとも言える。 つまり、命令デコードという観点からはベクトル機はスカラ機よりもさらに低消費電力的であると言える。 (NehalemのLSDはデコードにおいてスカラ機の弱点をベクトル方式に近づけることで省エネにしているとも指摘できる。)

考えても見て欲しい。x86では最近の命令追加はほとんどがSSEに代表される複数データを並列処理するベクトル命令系である。 これらは1命令で複数データを処理できるため、これらの命令が多用されるマルチメディア系処理ではデコード効率を改善できる。 (もちろんHPC用途でも非常に効果的だ。特にFMA系命令の追加は劇的な効果があると思われる。) ベクトル処理の定義は先生によって微妙に変わるけれど、 広義に解釈している先生の場合はSSEのようなSIMD系データパラレル処理をショート・ベクトルと呼ぶ方もいらっしゃるわけで、 スカラ機の側がまねをして取り込んでいる技術の筋が悪いわけがない。

従って、この点が問題なわけではないだろう。

では、どこが問題なのであろうか?

その理由が現れている記事がここにある。 RAMBUSのTBI(3)という記事で、 記事自体はRAMBUSのインタビュー記事である。 これは非常に興味深い記事なので興味のある方はご一読いただきたいと思う。

この中で、インタビュアーである大原先生とRAMBUSのKevin Donnelly氏のやり取りに このようなものがあるので引用させていただこう。

大原先生:「これに関連する話ですが、HPCのマーケットをどう思いますか? 例えば先月NECは新しいVector ProcessorのSX-9を発表しました。 このSX-9は256GB/secの帯域を持っていますが、NECはこれを実現するためにダイエリアの40%をMemory I/Fに割いているそうです。 こうしたマーケット、つまりVecrot ProcessorとかClusterこそが、真に高いMemory Bandwidthを必要としているように思うのですが?」

Kevin Donnelly氏:「その通り。我々はTBIのターゲットとしてGame ConsoleやGraphics以外にHPCも主要なターゲットにしている。 Vector Processorなどは、まさにこうしたターゲットだろう。だから、 今から4年後には、TB/secの帯域がこうしたマーケットで必要になってくるだろう。」

内容も興味深いのであるが、今回のネタで一番重要なのは 「このSX-9は256GB/secの帯域を持っていますが、NECはこれを実現するためにダイエリアの40%をMemory I/Fに割いているそうです。」 という点だ。

つまり、ベクトルプロセッサでは高バンド幅を実現するためにダイ面積の40%をメモリI/Fに割いているという事は、 チップ間アクセスのためのドライバ回路がスカラプロセッサよりも圧倒的に多いということに問題の本質が隠されていると思われる。

当サイトは前々回のコラムでサウスブリッジとCPUを統合する事を提案したが、 その際に電力効率が低下する事態はシステム全体では回避出来るとの予想を掲載したことがある。 「なんですか? そんな事をしたら電力効率が悪くなる? いやいや、確かにチップ内の電力効率は悪くなるけれど、 チップ間アクセスの消費エネルギーがチップ内アクセスの消費エネルギーで済むようになるので、 これで十分キャンセルできると思いますけどね。汎用度の高い回路構成によりチップ内の消費電力が増えても、 チップ間アクセスがDRAM以外無くなる事でシステム全体では十分におつりが来ると思いますが...シロウト考えかもしれませんが!? 」 と書いた部分がまさにその意味を表現した部分だ。

電気的に信号を伝送する場合には伝送距離と消費電力には相関があり、遠距離ほど消費電力が増える。 遠距離だと信号が減衰するし、それでもノイズに打ち勝たなくてはならないためだ。 つまり、ダイ内部でデータをやり取りする場合は、通常はミクロンオーダーで、どんなに遠距離でも数mmで済むものが、 チップ間だと(MCMを除けば)最低でも数cm、通常は数十cmの伝送距離となるので、 チップ内アクセスで済むことをチップ間アクセスでやると消費電力が激増するのである。

ここでベクトル機のメモリアクセスを考えてみよう。 ベクトル機はキャッシュを持たず、メモリ・レイテンシ隠蔽はマルチバンク同時アクセスによって成し遂げている。 AVL(平均ベクトル長)が短くなると急激に効率が低下するのはそのためであり、 また、バンク・コンフリクトが数少ない弱点になるのもそれが関係している。

要するにメモリのレイテンシを隠蔽するためにチップ外部にある主記憶にドカッと多重アクセスしなければならない事が ベクトル機の消費電力を増やしている主な原因であると当サイトでは推測している。 (逆にスカラ機が低消費電力なのは、データの局所性を利用してメモリアクセスの頻度を低減しているからであると指摘できる。)

これがベクトル機の消費電力が大きい原因だとすると、 チップ間アクセスをチップ内アクセスに変えることが出来れば消費電力を大きく下げることが出来うると考えられる。 というわけで、チップ間アクセスを減らす事もまた低消費電力達成のための有力な手段となり得ると思う。

☆ちょっと本題から外れるけれど...   
ここで、ちょっと本題から外れるけれど、ベクトル機の消費電力について考えさせられる事があるので述べてみよう。

上記の見解が正しいとすると、ベクトル機はLINPACKのようなキャッシュが良く効く用途では筋の悪いアーキテクチャであると指摘できる。 この場合、性能面では両者に大きな差はでないが、消費電力面ではベクトル機は不利となる。 なぜならば、キャッシュというチップ内アクセスで済む所をマルチバンク同時アクセスというチップ外アクセスで行っているからである。

しかし、B/F比が高くキャッシュが効かない用途ではどうだろうか?

この場合はスカラ機もメインメモリへのアクセスが性能律速段階となり、 メモリバンド幅の限界まで主記憶アクセスというチップ外アクセスが頻発する事になる。 その結果、理論ピーク性能が発揮出来ない事となり、効率低下が発生する。 これが流体分野でスカラ機は効率が10%程度しか出ない最大の理由である。

結局、メモリのバンド幅あたりの性能はスカラ機もベクトル機もほぼ同一となり、 その結果、実効性能当たりの消費電力はスカラ機もベクトル機もほぼ同等となる事が予想できる。 スカラ機の場合は消費電力が激増する訳ではないが、 アプリのB/F比が上がると同じ消費電力でも効率が低下していくために、 実質的に電力効率が低下してしまうわけである。

つまり、LINPACKでは消費電力にスカラ機との間に大きな差が生じてしまうベクトル機であるが、 実は流体計算のような用途では決して電力バカ食いというわけではないというのが当サイトの予測。 たしかに消費電力は大きいのであるが、スカラ機は同等なレベルで効率が低く、 結局差し引きすればスカラ機とほぼ同等の電力効率になると推測できるのである。 (スカラ機は消費電力が低いのであるが効率低下により同等レベルで性能も低下し、 その結果、実効性能当たりの消費電力はベクトル機とほぼ同等になると推定できる。)

要するに、バンド幅がボトルネックになっている場合はベクトルでもスカラでも 同一実効性能を得るために必要な総ドライバ回路数は、両者が同一技術水準で作られていると仮定すればほぼ同じとなる理屈である。 ベクトル機用のチップは確かにメモリI/Fが占めるダイ面積がチップの40%にも達するわけで、一見筋が悪いようにも思える。 けれど、スカラ機も効率が悪い分だけシステム全体でのチップ数を増やさざるを得ず、その結果、システムトータルでのメモリI/F面積は増えて、 ベクトル機でのドライバ回路の総使用量と同一となったところで実効性能も同じになると推定できる。

もちろん、これはシステム全体での総メモリバンド幅がベクトルとスカラで一致した時に、 両者のシステム全体での実効性能が同一になるという仮定が成り立つことが前提だ。 しかし、実際はメモリのバンド幅だけではなく、ネットワークのバンド幅という問題がある。 たとえば、BG/Lの場合ではボトルネックになっているのはメモリのバンド幅ではなくネットワークのバンド幅である。 (このことは、これを書いたときに証拠となる論文も含めて説明した。) 従って、上記の話は「ネットワークバンド幅が問題にならないケースでは。」という前提条件が付いている事にもご注意いただきたい。

具体例を見てみよう。当サイトは以前、下記のデータを掲載したことがある。

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

このデータであるが、最初に掲載したときは、なぜこのような逆転現象が起きるのか よくわからなかった経緯がある。もちろん、ベクトル機が効率が高いことによる逆転現象であることは わかっていたのであるが、より根源的な理解へと到達できていなかったのである。 (また、これについては読者のお一人から一部の例外的事例であり一般化は出来ないという意見を頂いたこともある。)

しかし、メモリアクセスのためのドライバ回路が多くの電力を消費している事が最大の原因と考えれば、 どうだろうか?  この表のように2倍ものレートでベクトル機優位な事態が常時発生しているかというと、 これを説明するためには別の理由を追加しなければならないが、 実効性能当たりで同レベルの消費電力という事態は一般的に発生していると思って良いであろう。 (今回の理由では逆転ではなく同一レベルになる理屈だが、同一ではなく逆転になる理由は後編で述べたい。)

ここで、結論を簡単にまとめて、スカラ機のB/F比、ベクトル機のB/F比、アプリのB/F比から消費電力の関係を想像してみよう。 (この場合は常にB/F(スカラ)<B/F(ベクトル)である。)

このときアプリのB/F比によってベクトル機の消費電力が相対的にどう変化するか?

B/F(アプリ)<B/F(スカラ)<B/F(ベクトル)の場合は ベクトル機は消費電力的には非常に筋が悪いアーキテクチャとなる。LINPACKはまさにこの状況であり、 従ってLINPACKでのPOWER項目の評価はベクトル機にとっては非常に都合の悪い結果となる。 (当サイトは時にベクトル信者呼ばわりされることもあるが、 当サイトは結論先にありきのエセ科学的評価はしない。 従って、この分野ではベクトル機の電力効率が悪いことは自らの仮説に従って素直に認める。)

B/F(スカラ)<B/F(アプリ)<B/F(ベクトル)の場合でも ベクトル機の負けであるが、この場合の電力効率は世間で言われているほどには差は付かない。

B/F(スカラ)<B/F(ベクトル)<B/F(アプリ)の場合では ついに差がほとんど無くなって、ベクトル機とスカラ機の優劣は消費電力面からはつかない事になる。

もちろん、ベクトル機が一番良い状況でもスカラ機とほぼ同等なわけだから、今回の論理では 電力効率面での優劣はスカラ機優位である。ただし、注意すべきは消費電力面は価格面と並んで ベクトル機にとってもっとも欠点とされる評価事項である事だ。 B/F比がB/F(スカラ)<B/F(ベクトル)<B/F(アプリ)という関係を満たしていれば、 ベクトル機最大の欠点が一つ消えるのであるから、このような用途での評価は別の項目で決着する事になるだろう。

ちなみに、地球シミュレータで使用している地球温暖化研究用アプリはおそらくこの関係を満たす。 なぜならば、地球シミュレータ、SX-8R、SX-9の演算効率データから、 アプリのB/F比が最低でも4を超えることが推測できるからである。

従って、スカラ機のB/F比が大きくても1程度である事を考えれば、 地球シミュレータの消費電力が大きい問題点は実効性能が当初の想定より4倍以上も大きかった事実により相殺され、 電力効率としてはプラスマイナス・ゼロになっているハズである。 つまり、地球シミュレータの高消費電力と高性能は同一起源の"光と影"であって、 消費電力が大きいという地球シミュレータの弱点は(地球温暖化予測という主用途を考えれば)高演算効率によって相殺され、 致命的欠点ではないと考えるべきものである。 実際、ESがIPCCで多大な成果を上げたという事実からみて、消費電力過多という欠点は十分に埋め合わされている。

これ、この程度の話は脳みその足らない当サイトでさえ思いつくのだから、プロ間では常識として知られているのかと思いググってみた。 だが、当サイトの探し方が悪かったのかそれらしい論文は見つからなかった。

そこで当サイトからの提案であるのだが、プロのアーキテクトの方々で、スカラ、ベクトル、アプリの各B/F比と電力効率の関係を 検証してみたらおもしろいのではないだろうか?  おそらくアーキテクチャの評価論文が一つ書けるだろうし、当サイトの推定が正しいにせよ間違っているにせよ、 プロレベルで真実を知ることができればこれ以上興味深い話は無い。

と、まぁ、余談が長くなってしまったが、省エネという意味ではチップ間アクセスを減らすという方向性は、 CPU内部のアーキテクチャ的な省エネや、SOIプロセスや高誘電率ゲート絶縁体のようなプロセス的な省エネと並んで非常に効果的な省エネ技術だろう。 なぜならば、PC用途はHPC用途とは事情が異なり、キャッシュがほとんど効果を示さないアプリはPC用途では少ないからである。 また、intelがNehalemにおいてメモリコントローラを統合しようとしている事も、 FSBをチップ内アクセスとすることで省エネに貢献していると言える。 (ただし、オンチップメモリコントローラによりDRAMのレイテンシ問題が緩和されるので、 その結果Nehalemではキャッシュ容量増強には力が入っていない。 これはキャッシュ自身の消費電力は減らすものの、ミスヒット時のDRAMアクセスによる消費電力増大を招くので、一長一短。 場合によっては消費電力増大を招くと考えられる。)

次回はチップ間アクセスを減らすという意味でBG/Lを、 また、キャッシュベース・アーキテクチャがHPC分野で消費電力面からも不向きである点についてCELLなどを参考に、 さらに省エネな方向性について(アマチュアながら)考えてみたい。



1)
ごめんなさい。見栄張ってカッコつけました。 正直に言います。メタボ対策です。トホホ。

−引用元の参考文献−
"Supercomputing Challenges. at the National Center for. Atmospheric Research". Richard Loft, NCAR, USA