Nehalemの絶対性能とAtomの高効率を狙う!?   

2009年10月4日



☆DRAM価格で景気回復を実感。   
住居の近くにPCパーツショップが無い当サイトの居住環境。 ネットショップ以外で買おうと思ったら一番近くの小さなショップでさえ30分以上車を走らせなければならない。

そんなわけで、何か物を買おうとするたびにいろいろなところに車を走らせる。 で...田舎なので周囲には秋の風景が...萩に彼岸花が真っ盛り。 ホント...PCパーツショップさえ身近にあればとても風情のある良いところなんだけど... 何もかも上手く行くという話は無いもんだね〜。

萩と彼岸花。秋の風情は良いのだけど...
でもPCパーツショップへは小さなお店でも最短で車で30分以上。トホホの田舎暮らし。

そんな状況下、増設メモリを買おうと思ったらDRAMが値上がり傾向にあることに気がついた。

去年は暴落状況であったDRAM価格が、ついに値上がりに転じたようだ。 PCマニアとしては夢の宴終演となるわけだが、これは明らかに景気回復の兆候。 DRAMメーカーだけではなく、日本全体としてもありがたい状況であろう。 当サイトの考えは以前ここで述べたけど、 価格暴落は結局はPCマニアの懐を痛めてしまうというもの。 適正価格へ向けての値上がりは決して価格高騰ではないと認識し、ある程度の値上がりは許容すべきと思う。

行き過ぎと言えば、ここで例に掲げた派遣労働の件もおもしろい結末を迎えたね。 経済界は政治力を使って派遣労働を合法化させた。それどころか裁量労働制という名の下に ホワイトカラーエグゼンプションを導入し残業さえタダ働きにしようと企んだ。 しかし、行き過ぎは必ず反動が跳ね返る。

選挙では派遣労働を合法化した与党に対する批判が沸騰。民主党が与党となった。 当サイトは有権者が積極的に民主党を支持していたとは思えず、 今回の選挙結果は与党に対する懲罰という意味合いが非常に強いと感じている。 要するに民主党が勝ったのではなく自公連合が負けたのだ。

ここで派遣労働が正しいか間違っているかという論考は抜きにして、 この結果を経営者の戦略眼という観点から見てみよう。 結果、経済界が主張するホワイトカラーエグゼンプションどころか現状の派遣労働制度さえ失う事となるは必然である。 要するに経済界トップはどこが落とし所かをまったく読めておらず、 かえって自らの利益を棄損する結果を招いたのだった。

日本の強みは高い現場技術、弱みは戦略が読めない経営トップ。 これは当サイトの考えだが、トップクラスの経営学教授にも同じ考えの方が居る事は一言言っておきたい。 その戦略が読めない経営トップがまたも状況を読めていなかったのが今回の選挙結果と言えると思う。 日本企業には強みと弱みがあるが、社内での出世競争に強いだけで戦略眼を持つ目利き経営者が育たない事が 日本企業最大の弱点だと思う。(経営者の資質にはいくつかあるかと思うが、 当サイトは戦略的目利きである事こそがもっとも重要な資質と考えている。 最近は一部に戦略眼のある経営者が出てきたと思われる事が唯一の希望だけど...)

と言うわけで、我々PCマニアはこれと同様な判断ミスには陥らない事が肝心だ。 DRAMベンダーが現状の大赤字から脱却し、わずかに赤字程度になるまでの値上がりは許容すべきと思う。 それが結局はかえって我々PCマニアのためにもなると思うからだ。

☆PC用途におけるマルチコアは過大評価過ぎる。   
と言うわけで、今回は余談もPCパーツネタだったけど、本題へ。 今回は前回の続きネタ。フラッグシップ更新ネタは次回に回す事にした。

当サイトはPC用途におけるマルチコア化の状況はアプリの対応状況から見て過大評価であるという意見だ。 マルチコア化で性能が向上し続けられる状況にはほど遠く、 特にデュアルコアならばまだしもクアッドコアは対応アプリを使わない限りほとんど意味が無い。 自分で使っていて複数のアプリが同時稼働するのはセキュリティー関連やWebサイトを同時に複数開くとき位なので、 SMTのような機能さえ付いていればシングルコアでさえまだまだ実用的と言っても言い過ぎではあるまい。

その問題点はPC用途ではマルチスレッドで動作する時間がまだまだ短いという点にある。 実際、対応アプリを使わない限りデュアルコアであるAtom330よりもシングルコアであるCeleron-M440の方が高速だったし、 デュアルコアであるAtom330でCPUがフル稼働する時間は意外に短い。 だから、もしCeleron-M440にSMTのような機能が付いていれば 対応アプリを使わない限りシングルコアでも大きな不満を感じることはない。 シングルスレッド動作している状態では1コア以外は全部遊んでいるわけで、 実態としてはマルチコアは動作効率が非常に悪いと思う。 (ポラックの法則 vs アムダールの法則の戦いは、現状ではアムダールの法則の圧勝である。)

当サイトがHyper-Threadingのような技術を重視するのには理由がある。 ユーザーがシングルコアで感じる不満点というのは多くの場合で性能不足ではなく、 動作対応の問題なのではないだろうか?という疑念が頭の中にあるのだ。

たとえばシングルコアでは2つのアプリを動かしたときに一方のアプリの反応が鈍くなる場合がある。 これはデュアルコアだと問題が少なくなる場合が多い。 これは一見すると数少ないマルチコアの優位点だ。

しかし、この場合は全体の処理時間に大差がある訳じゃないのだ。 (単純にポラックの法則を適用すれば同一ダイ面積ならばデュアルコアの7割程度。 ただし、アプリが1つしか稼働していない場合はシングルコアが約4割速い。) 応答を鈍くしているのは応答が求められていないアプリ側がガンガン処理を行っているからであり、 システム全体での処理はちゃんと進行している。 大差があるように感じるのはアプリAが負荷の大半である場合にアプリBがユーザーの求める対応だった場合である。 これはデュアルコアではなくSMTのような技術でも改善可能であろう。

つまり、シングルスレッド性能を落としてまでマルチコア化を進める必要性は(アプリの対応が現状のままでは)ほとんど無く、 たまに生じる複数アプリの同時稼働に関する応答性の問題はSMT系の技術で対応可能と考えている。

ではなぜマルチコアなのか?と言えば、それはシングルコアの性能が高められなくなってしまったからだ。 はっきりしているのは、マルチコア化は積極的に選ばれた戦略ではなく消去法でやむなく残った選択肢であるという事だと思う。 いわゆる「3つのウォール問題」である。

☆徹底的な共有を目指す。   
そこで、今回はコア数を増やす方向性ではなくマルチコアに分割できるシングルコアを考えてみる。 逆にマルチコアをシングルコアに融合できる形でも良い。 たとえばintel製の場合は現状でも2次以上のキャッシュは共有されている。 これはシングルスレッド動作する場合にキャッシュ容量が事実上増えるという効果がある。 この共有化という概念を他の部分にも延長してみよう。

キャッシュの次はデコーダーだ。 現状のCPUではデコーダーは、簡単な命令しかデコードできないシンプルデコーダを2〜3個と、 全命令をデコードできる複雑なフルデコーダー1個で構成されている場合が多い。 要するにコードの多くは簡単なもので、命令の出現頻度には大きな偏りがあるというわけだ。

ここで問題なのは、単純なマルチコアの場合はいかなるアーキテクチャでもコア1個につき最低1個のフルデコーダーを必要とすることである。 そうでないとデコードできない命令が発生してしまうからだ。 しかし、ポラックの法則に従えばマルチコアが有効な場合はコアがシンプルな方がコア全体としては効率が良い。 つまり、シングルスレッド動作時には余分なフルデコーダーが他のコアで余っている。

ここで、デコーダーを共用できればシングルスレッド動作時のデコーダー数を高めつつ、 マルチコア動作時でも1コアに1つフルデコーダーを用意する必要は無くせるのではないだろうか? 

複雑なコアの場合、シンプルデコーダー2〜3個とフルデコーダー1個ということは、 フルデコーダーを必要とするコードの出現頻度は多くても1/3〜1/4程度という事になる。 そうでなければフルデコーダーで無ければデコードできない複雑な命令がボトルネックを作ってしまう。 つまり、フルデコーダーを単純なスカラプロセッサ4コアで共有できればフルデコーダー計4個がシンプルデコーダー3個+ フルデコーダー1個でもそれほど大きな性能低下は起きないと予想できる。 もちろん共有のための調停用ハードウエアや配線も必要だから単純に計算通りにはいかないかもしれないが...

また、トレースキャッシュ方式を採用すればもっと都合がよい。 なぜならば、あるスレッドがトレースキャッシュにヒットしている間はデコーダーに余力ができる。 つまり、あるスレッドがトレースキャッシュにヒットしている間は他のスレッドを全リソースを投入して全力でデコードできる。 とすると、同程度の性能を維持する場合でも、さらに少ないデコーダー数で足りる計算になる。

この場合はシングルコアと違ってヒット率がそれほど高い必要性もない。 たとえばヒット率が80%だとしたら、2スレッドが同時にキャッシュミスする可能性は単純計算では4%しかない。 バッティングさえしなければ良いからだ。

NetBurstアーキテクチャではデコーダーが1つしか無いのが弱点だと言われていた。(一つだから当然フルデコーダー相当である。) 当サイトは、最初はトレースキャッシュにヒットすればデコードの問題点は事実上緩和できるわけだから それほど問題にならないのでは?と考えていたのであるが、 その後にトレースキャッシュはトランジスタ効率が通常のキャッシュより悪いだろうと気付いてちょっと考えを変えた経緯がある。

しかし、デコーダーが複数有ればどうだろうか?

1コアのみのために複数のデコーダーを用意するのはトランジスタ効率が悪いだろうから、 NetBurstアーキテクチャでは実現不可能だったのだろう。 なぜならば、ただでさえトレースキャッシュにヒットしている状況では動作が停止してしまう デコーダーの回路規模がさらに大きくなるわけだからね。

しかし、マルチコアで共有する形ならばマルチコアの効率性を維持しつつ 若干効率は下がるもののシングルスレッド性能を向上できると思う。 各スレッドが同時にトレースキャッシュミスする可能性は、共有コア数が増えるほど発生確率が減るからだ。 (素人考えかもしれないが、共有数が増えるほど動作の揺らぎが減ると予想される。)

また、デコーダーの処理能力が高いわけだから、その分トレースキャッシュの容量を減らすことができるハズだ。 キャッシュミス時のペナルティーがデコーダーが1個しか無いNet-Burstアーキテクチャより少ないわけだからね。 つまり、普通の一次キャッシュを同クラスのライバルと同程度搭載すれば、 Net-Burstでの12k-μOPsよりずっと少ない容量でも十分な効果を上げることが可能になるという予想だ。

トレースキャッシュの弱点が実効的なキャッシュ容量に対するトランジスタ効率悪化であると当サイトでは過去に推測した。 (ふやけた解凍済み命令(CPUマニアのぼやき編)をご参照ください。) トレースキャッシュの話を持ち出すと「たるさんはトレースキャッシュを過大評価しすぎ。」とまたも失笑を買っているかもしれないが、 トレースキャッシュ容量を減らしてもペナルティーの少ないアーキテクチャならば再採用の可能性は否定できない気がするね。 (あっ、いや...今回はAMDの話だから再採用では無いね。)

実行ユニットも共有だ。 これについては以前効率アップで省エネ?(実行ユニットの共用)で書いたので省略するが、 実行ユニットも共有すれば性能が上がるし、逆に性能を維持できれば良いのならば共有コア数の1/2乗分の1にまで実行ユニット数を減らせると思う。

もう1点追加すれば、実行ユニットにもデコーダーと同様な事情があることである。 たとえば、デコーダーがシンプルデコーダーとフルデコーダーに分かれているように、 ALU(整数演算ユニット)も全命令を実行できるものと、簡単な命令のみを実行できるものに分かれる場合がある。 性能面だけを考えればもちろん全命令を実行できるALUが良いが、 出現頻度の低い命令のために全ALUを全命令実行可能タイプにするのはトランジスタ効率が悪い。 一方、コアを共有しない単純なマルチコアの場合は各コア毎に最低一つは全命令実行可能タイプなALUが必要である。 でないと実行できない命令がでてきてしまうからだ。

だったら、命令の出現頻度に合わせる形でデコーダーと同様に複数のALUを共有した方が良いのではないだろうか?  たとえばFPUではコア間での共有は既に先例があって、サーバー用CPUであるNiagaraでは複数のコアでFPUを共用していた。 Niagaraのような用途ではFPUは重要な地位を占めないが、ユニット数がゼロでは問題があるからだ。 これと同じ発想である。

また、Net-BurstアーキテクチャではALUのみに2倍速を利用するというメカニズムが採用されていた。 これは一種の逐次実行だから依存関係によるネックを解消しやすいだろうけど、 周波数2倍だから消費電力は激増した。しかし、コア数が多くても共用できればこのような強引な 高速化も一部ALUに限って限定的に搭載が可能になる可能性がある。

通常のマルチコアではこのようなALUを採用すると各コアに最低1個搭載する事になるが、 全コアで1個搭載で済むならば依存関係が厳しくて高速化が必要な瞬間だけそちらに流すという 発想で電力激増を防げる可能性があるだろう。 シングルスレッドの場合は非共有部分が1コアを残して止まるわけだから消費電力が減るわけで、 その際には2倍速ALUをフル稼働させればよい。消費電力は高まるが他の部分の消費電力は減るから、 効率は落ちるもののトータルの消費電力はマルチスレッド動作時を越える事はないだろうから。

ALU同様にFPUも共用だ。 こちらはALUよりも回路規模が大きいから、調停のハードウエアによって費用対効果が減ってしまう影響を小さくできるメリットがある。 また、もっと言うとAMDはGPU混載を主張しているから、FPUはGPUと共用という手だってあるだろう。 GPUはユニット数から言えばFPUのお化けだから、リソースは有り余るほどある。 (倍精度どうするか?とかの問題はあるけれど...) もちろん、この場合はGPUとCPUが超密結合とならざるを得ないから、設計の難易度は激増するだろうけどね。

なお、デコーダーを共有するということは、ほぼ自動的に1次命令キャッシュも共有となる。 つまり、設計上はキャッシュ周りの設計難易度が、かなり高まるのではないだろうか?  おそらく、アーキテクトには腕の見せ所となるだろうね。

☆それだけやっても...シングルスレッド性能はあまり向上しないというトホホな予想。   
で...これ、書きながら気付いたのだけど、この概念はシングルスレッド動作時におけるマルチコアの非効率性を大幅に改善する効果はあっても、 シングルスレッド性能の絶対値は現状のベストソリューションと同レベル+αまでしか向上しませんね。

たとえば単純なスカラCPUの4コア版マルチコアとデコーダーが4つあるアウトオブオーダー機能付きスーパースカラCPUと、 今回の各種ユニット共有プロセッサを考えてみると良い。

この場合、当サイトが考える共有型CPUではフルデコーダーや全命令実行可能なALUが4コア版スカラマルチコアより少ないから、 マルチスレッド動作時の効率が高い上にシングルスレッド性能も高い。 負けているのはマルチスレッド動作時の絶対性能のみ。

しかし、アウトオブオーダー機能付きスーパースカラCPUと比べたらどうだろう?

アウトオブオーダー機能付きスーパースカラCPU側が仮にSMTを装備していたとしても、 ポラックの法則を考えればマルチスレッド動作時の性能はおそらくは圧勝。 だが...半導体プロセスが同一技術水準の場合に換算すれば、シングルスレッド性能は良くて同等+α程度だ。

というわけで、長々と理想と現実を考えてきた上でAMDがなぜBulldozerでクラスタ型アーキテクチャを採用するのかが見えてきたような気がする。 おそらくはBulldozerのシングルスレッド性能はNehalemと比べても飛び抜けて高いものとはなりそうにない。 開発時期が違うから絶対性能では優位だろうが、開発時期の差に見合った要因分(半導体プロセスやクロック周波数等)を差し引けば 同等程度の性能だと予想する。

それよりは、おそらくマルチスレッド動作時の電力効率で優位性が出ると思う。 Nehalemでは複雑なコアを採用している関係上、効率という面ではシンプルなコアに劣る。 これは、AtomとNehalemを比較すればよくわかる。 絶対性能ではNehalemが圧倒的に優勢だが、コア面積あたりの性能や消費電力あたりの性能で比べればAtomが圧倒的に優勢だろう。 同じダイ面積でNehalemとAtomを比べればAtomの方が断然コア数を増やす事ができる。 つまり、この場合マルチスレッド動作時における同一ダイ面積換算での性能はAtomの方がずっと高いはずである。

しかし、Atomはシングルコアの絶対性能ではNehalemに全然及ばないし、 デュアルコア以上のコア数でのAtomは発売されていない。 もしシングルスレッド性能がもはや時代遅れな概念ならばAtomでマルチコアを作ればよい。 同一ダイ面積換算ではAtomの方が圧倒的にコア数を増やせるから、マルチスレッド性能も効率も断然高いはずである。

これが、当サイトの主張する「PC用途ではまだまだシングルスレッド性能が最重要である。」という主張の根拠の一つとなる。 なぜクアッドコアAtomやオクタコアAtomが発売されないのか?という疑問に対する答えは、 「もしもそんな製品を発売すれば、マルチコアがPC用途でいかに役立たないかが簡単にバレてしまうから。」というものである。 シングルスレッド性能が無視できないからNehalemの出番となるわけだ。

だったらAtomの効率とNehalemの絶対性能は両立できないのであろか?  つまりそこが狙い目なのだ。そここそがクラスタ型アーキテクチャの狙い所なのだろう。 Bulldozerのクラスタ型アーキテクチャが当サイトの予想する姿と一致しているならば、 マルチスレッド動作時の効率はシンプルコアより若干悪い程度で済むだろうから、 このような動作状態でも消費電力あたりの性能がそれほど落ちないと予想できる。 (アウトオブオーダー機構搭載とすれば、さすがに電力効率でAtomに勝つ事は無理だろうけど。)

また、スレッド数が中途半端な状態でも効率を維持できる。 単純な4コアで2スレッド動作状態の場合、2コアが余ってしまう。 しかし、クラスタ型アーキテクチャならば1命令実行4コア動作状態を2命令並列実行2コア動作状態にする事も可能だから、 動作効率は4スレッド動作時に劣るもののコアの半分が余ってしまう状態を防ぐことができるだろう。

と言うわけで、AMDのBulldozerはシングルコアの絶対性能ではi7/5/3系に比べて開発時期が遅い分若干向上するに過ぎないと予想する。 しかし、マルチコア動作時には消費電力あたりの性能が大幅に改善し、 AtomにはかなわないもののNehalemよりかなり優秀な電力効率を実現できるのではないだろうか?

☆時間感覚を付け加えて予想すると...   
さて、今までの話は理想論であり、現実にそれをそのまま実現できるかどうかは 技術革新のペースの問題がある。要するに、やりたくても時間的に間に合わないとか、 理想論としては正しくても現実的な難易度から妥協点を強いられる、と言った話。

キャッシュを1次まで含めて共有し、デコーダーを共有し、実行ユニットを共有し... といったことをいきなり全部できるかというと、正直疑問。 たとえば実行ユニットの共有にしても、ハードウエア規模が相対的に小さいALUよりもALU比で大きいFPUの方が 共有のコストパフォーマンスは良いハズであるし、デコーダーにしてもスカラ4コアでの共有よりも 2並列スーパースカラ2コアでの共有の方が設計は楽だと思う。

現行のAMDは最高で6コアで各コアが3並列実行であるから、デコーダーはシンプル・フル総計で18個。 上記の理屈ではこれを全共有すれば18並列プロセッサとなるわけだけど、 単純にそこまで並列度を上げても4並列位から急激に性能向上ペースが飽和していくはずであり、 これ以上のシングルスレッド性能向上はごくわずかだと予想される。 それよりも共有度が上がれば上がるほど調停や配線のための投資が増えるはずだから、 どこかで効率ダウン要因が効率アップ要因を上回るようになる。

この当サイト的概念で行くとAtomは2コア融合タイプのスカラプロセッサと言うことになるが、 これは元々のコアがスーパースカラではなく単純なスカラベースとなるから効率ダウン要素が少なくて済むと当サイトでは考えている。 しかし、現実的な問題を考えれば18コアのスカラプロセッサ融合というのは難易度の割に効果が薄くなる可能性が高い。 で、直感判断ではあるが、当サイトでは2並列スーパースカラの2コア融合が現実的と思う。 1コア動作時の並列数はおそらく4並列が上限だろう。このような構成の場合はコア数は2のべき乗であるべきだが、 4並列のもうワンランク上の8並列は費用対効果が薄すぎると思うからだ。

と言うわけでAMDの方針が見えてきたように思う。 シングルスレッド性能は「3つのウォール」の壁の直前までにとどまり、 これがNehalemと比べて極端に上がることはないと予想する。 しかし、マルチスレッド動作時の電力効率は大きく改善すると思う。 狙いはシングルスレッド動作時にNehalemの絶対性能を、マルチスレッド動作時にAtomの高効率を、同一チップで両立させること だと予想する。

考えてみればこれはAMDの経営状態にも合っている。

一つはAMDの弱点であるノートPC用途で反撃ののろしを上げる事ができること。 Nehalemの狙いはAMDの牙城であったサーバー市場を切り崩すことだった。 ならば、AMDがintelの牙城であるノートPC市場を切り崩そうと考えるのはありそうなシナリオだ。 ノートPC市場ならば絶対性能よりも電力効率の高さをアピールしやすい。

もう一つは開発リソース不足を補える事。 AMDはintelに比べれば開発リソースの規模の違いは比べものにならない。 従って、用途に合わせて別々のコアを開発するのは開発リソースの集中投入ができなくなり、 各開発テーマ毎にリソース不足でintelに各個撃破されてしまう可能性がある。 だとしたら、絶対性能が要求されるPC用途、マルチスレッド性能や電力効率が要求されるサーバー用途、 高電力効率が絶対条件となるモバイルPC用途で共用できるアーキテクチャは開発リソースの集中投入という意味で AMDの経営状態に合致した戦略のハズである。