「秘伝のたれ」が世に広まる。(Haswell予想その1.)   

2011年8月29日



☆当サイト相変わらずの悩み事。それは頭の悪さ。   
まずはいつもの余談から...と言いたいところなのだけれど、 試験勉強が遅れに遅れているので余談を書くだけの遊びに行ける状況では全然ない。 で...試験勉強の気分転換に過去には散歩とかに行っていたのだけれど、 この8月では15分も歩けば汗だくになってしまうのでこれも不可。 節電で空冷も稼働できず扇風機で我慢だし、気分転換の散歩の話すら書けない状況だね。

肝心の勉強も、意欲が落ちていないというだけで進捗としては最低状況。 過去問の初回チャレンジで撃沈する話は友人の資格試験受験話でもよく聞く話なので恥ではないが、 過去問5年分チャレンジした段階でまたも撃沈とは我ながらどういうことかね?  相変わらず自分の頭の悪さ、特に記憶力の無さには閉口ですなぁ...

と言うわけで、こだわりのネタを深く考えて書ける状況ではない。 なので、今月の更新をゼロにしない程度での、正直な話時間稼ぎのつなぎネタで... (すみませんが、試験が終わるまではご容赦を。)

☆まずは思考のベースラインとして今後のトレンドを読む。   
当サイトはPCマニアサイトなので、一番のネタはPCネタ。 特にPCマニアと言っても種別としてはハードウエア系のさらにCPU系のマニアである。 (なので、ソフトの話はほとんど出てこない。) と言うわけで、直近の王道ネタはHaswell予想ネタであろう。

当サイトは、今後のCPU開発のトレンドとして下記の3点を強調してきた経緯がある。 一つはマルチコア性能を向上しようとするあまりシングルスレッド性能を犠牲にするなどという設計思想に絶対にしてはならないという主張。 「マルチコア化は時代の流れである。」という主張には当サイトは(PC用途としては)大反対の立場であり、 「シングルスレッド性能向上が3つのウオールによって困難になったため、マルチコア化はやむなく導入された苦渋の選択である。」 という意見である。(もちろんサーバー用途等では有効なので、マルチコア化技術そのものを否定している訳ではない。)

もう一つは低消費電力化の重要性が性能指標に取って代わる時代に移り変わりつつあるというトレンド予想である。 (当サイトでは2010年3月に異分野から利益を奪え。(高性能から低消費電力へ。)というコラムを書いた。)

この発想が間違いではなかった点はintelのUltrabook構想で事実をもって証明されたと思う。 Ultrabook構想では性能向上も叫ばれてはいるが、最大の主張点はTDPの大幅な削減である。 要するに性能を現状のメイン+α程度に留めたまま消費電力をAtom程度にまで大幅に改善する構想なのである。

ちなみに、消費電力あたりの性能向上という意味ではスペック上はコアをシンプル化してコア数を増やすのが単純明快な解決方法である。 が...Ultrabook構想ではこのような方向性は万に一つも考えられないと予想する。 あくまでシングルスレッド性能を維持した状態でのTDP削減という、難易度の非常に高い目標を承知の上であえて掲げてチャレンジしていく方針と思われる。 (マルチコア化で楽して達成しようとすると、スペック上は低TDPになっても実効性能面でユーザーに見捨てられる事になるからね。)

また、今後のCPU開発を読む上ではクラウド化の進行に旨く対応する意味でもTDPの削減は最重要課題だろう。 データセンターが巨大化する一方の現状では、消費電力コスト、廃熱コストの削減は最重要課題。 クラウド型のデータセンターは今後も巨大戦艦化する一方であるはずだから、 CPUの改良で管理運用コストが大きく下げられれば商売上非常に有利な立場になれる。 なお、性能向上という意味ではこちらはマルチコア化での性能向上が十分に可能だから、 サーバー用途CPUでは今後も着々とマルチコア化の進行が進むと考えられる。1)

3点目はGPU混載の重要性だ。 GPU混載はSoC化の必須項目であり、タブレット用途等では外すことは即完敗を意味する絶対条件になる。 PC用途では全製品では絶対条件では無いが廉価領域ではやはり絶対条件だし、 GPU混載によるトレンド転換の影響度の大きさを考えたらこれも絶対に外せない最重要項目だ。

また、消費電力削減という意味でもGPU混載は重要である。 両者が被るハードウエアを共用する事で低消費電力化できるし、 何より両者間での外部アクセスが内部アクセス化できる事による電力効率アップは目玉商品になるだろう。

☆Haswellはデュアルコアかクアッドコアでのハードウエアリソースの共用を行ってくるであろう。   
と言うわけで、今後の基本トレンドを予想し、 このトレンドを実現するという意味でHaswellを予想してみよう。 つまり、当サイトがHaswellの技術開発を推測するのではなく、 当サイトの思う理想CPUアーキテクチャの方向性を書いていけば、 それが自動的にHaswellの予想になっているハズだという発想である。

要するに、「シングルスレッド性能の向上」、「低消費電力化」、「GPU混載のさらなる進化」、「シングルスレッド性能を犠牲にしない上でのマルチコア化」 という4点がHaswell予想の重要ポイントだ。

まず、「シングルスレッド性能の向上」と「シングルスレッド性能を犠牲にしない上でのマルチコア化」の同時達成について考えてみよう。 問題点はPC用CPUとサーバー用CPUではマルチコア化の影響度が全然違うという事である。 PC用CPUでは2011年後半に入ってすら主流コア数はデュアル。 現状では対応アプリを使わない限りクアッドコアには全然意味が無いのだから、 アプリ対応がある程度進む将来の話を考えたとしてもワンランクアップのクアッドコアを想定するだけで十分すぎると思う。

もちろん、PC用CPUとサーバー用CPUで別々のアーキテクチャを考えれば、それぞれ個別に最適化はできるだろう。 しかし、その場合は開発コストが約2倍になってしまう。 つまり、共用できる範囲をデュアル〜クアッドに限定することでサーバー用途を想定したアーキテクチャでもPC用にも十分流用でき、 逆に進みすぎたマルチコア化でシングルスレッド性能が問題になっているサーバー用途でもポテンシャルの復帰が可能となる。 また、開発コストも大幅に削減できる事になる。

すると、Haswellの予想が一つできる事になる。 つまり、ハードウエアリソースの共用という当サイトが過去に予想した進化のベクトルはデュアルコアかクアッドコアの段階までで引き留めてよく、 それ以上のコア数が必要な場合はPC用途を想定する必要性が皆無だから、単純にマルチコア化を進めればよいという発想である。 これ以上のコア数で共用を行うと、マルチコアがあまり有効ではないPC用途でも共用したコア数分以下での製品化が原理上不可能になってしまうという問題点がある。 ソフトのマルチスレッド対応率が今後劇的に向上する可能性はゼロに近く、その結果PC用途で想定すべきコア数は現状でデュアル、将来を考えてもクアッドで十分だ。 つまり、この段階で当サイトとしてはハードウエアリソースの共用による低消費電力化はデュアルかクアッドでの共用というステップになると予想できるわけだ。 (ちなみに、当サイトはPC用途ではマルチコア否定派最右翼なので、AMD同様にデュアルコアレベルでの連結の方が可能性が高いと思う。)

AMDでは既に2コア間でのハードウエアリソースの共用を行っている。 この方向性はマルチコア化においてコア数を2倍にしてもハードウエアリソース量が2倍にならない上に、 同時にシングルスレッド性能もアップできるという非常に重要なメリットがある。 もちろん、マルチコア動作時の性能アップでは単純なマルチコア化に負けてしまう事になるが、 PC用途では対応アプリ無しでそのような動作状況になる可能性は極めて低いからメリットがデメリットを断然上回ることになる。

また、「シングルスレッド性能の向上」と「低消費電力化」の同時達成という意味でも重要だ。 シングルスレッド性能アップをリソースの共用無しで行ったコアを単純にマルチコア化すると、 ダイサイズが限りなく肥大し、その結果消費電力もコストも許容範囲を完全に逸脱してしまうことになるからだ。

と言うわけで、当サイトのHaswell予想その1。 Haswellはデュアルコアかクアッドコアでのハードウエアリソースの共用を行ってくるであろう。

☆HaswellはμOPキャッシュのさらなる進化がキモ。   
注意点は、もしこの予想が当たったとしても、それは決してAMDの技術のコピーではないという点である。 予想が当たったとして、もしintelが「これは弊社独自の技術で作成した。」と主張してもウソはなく、 それはどこぞの国の鉄道の話とは全然違う。

それはなぜか?  それは当サイトが以前からトレースキャッシュの重要性を決して見下してはならないと主張してきた点に秘密が隠されている。

x86には過去のソフトの安定した利用性という最大のメリットがあるが、 このメリットがもたらすハードウエア上の数少ないデメリットとしてデコード系の肥大化が指摘できると思う。 ここを単純化できれば消費電力を大幅に減らすことができるが、RISCプロセッサでやっている対応のような方法を単純に導入すると x86互換性の維持という最大のメリットを失うという致命的な問題がある。 互換性問題はx86では生死に直結するからだ。

従って、デコード系の消費電力を削減するためにはトレースキャッシュ(μOPキャッシュ)にヒットさせればよい。 AMDの方法だとコア間での共用により効率は高まるが、 キャッシュが導入されている訳ではないので2コア動作時には1コアあたりの性能が落ちてしまうという問題点がある。 また、デコーダーは常時稼働する必要性があるので消費電力削減効果もその分薄まってしまう。

これがμOPキャッシュだとどうなるか?  キャッシュヒットしていればデコーダーは動作の必要性がないので電力効率は上がる。 また、共用により2コア同時デコードを行っていても、 一方がキャッシュヒットしていればデコーダーはもう一方のデコードに専念できる。 つまり、一方がキャッシュヒットしている限りは、2コア動作時にもデコード性能低下が発生しない理屈になる。

つまり、当サイトの考えでは、コア共用による性能アップ、低消費電力化のためには、 AMDの手法よりもintelのμOPキャッシュの方がかなり効果的だと予想する。 命令デコード面ではx86はARMより不利と思うが、これならば キャッシュヒットしている限りはARM相手だって遜色なく戦えるように改良できる可能性があるだろう。

つまり、μOPキャッシュの理想型としてintelは最初からマルチコアでのキャッシュ・デコーダーの共用を想定していたと当サイトは推測していたのである。 で、AMDの方法よりもμOPキャッシュの方が効果的と考えていたので、 AMDのトレースキャッシュ採用説を過去に掲載したこともある。 でも、AMDの現行方法はμOPキャッシュ型ではなかったので、当サイトの予想は外れた。

実はこれには理由がある事が後日判明したのである。 トレースキャッシュの開発時にintelが特許を出願していたという報道が後日あった。 なるほど、これではAMDがμOPキャッシュを採用しなかったのもうなずける。 AMDが現行方法を用いたのはμOPキャッシュ方式を使いたくても使えなかったからなのだろう。

また、同じ事はトレースキャッシュを初めて採用したNet-Burstアーキテクチャでも言える。 Net-Burstではキャッシュヒットを前提にして命令デコーダーが(たしか1命令分にまで)縮小されていた。 しかし、キャッシュヒットしなかった場合のことを考えると今のCPUのように3〜4命令の並列デコードを行う必要がある。 ただし、トレースキャッシュには通常キャッシュよりもダイサイズが大きくなると言うデメリットがあるから、 命令デコーダーの拡大と同時に行うのは難しい。

しかし、3〜4命令の並列デコーダでも2〜4コアで共用使用すれば、 それは肥大化を事実上1/2〜1/4に抑制できたことになる。 つまり、高並列デコードを事実上低ハードウエア量で実現できる事になるわけだ。

と言うわけで、当サイトのHaswell予想その2。 Haswellではデュアル、またはクアッドでのハードウエア共用が行われると予想したが、 そのキモはデコーダーの共用化がμOPキャッシュ方式で行われるという点であると予想する。

これにより、共用の効果は性能面でも消費電力面でもAMD以上に効果的になるハズだ。 また、この予想が正しければ、Haswellではキャッシュ部分が最も重要なコア技術になる。 当サイトが以前考えた「老舗うなぎ屋の秘伝のたれ」こそが、 Haswellのコア技術であろうと予想する。 Haswellの核心部分はμOPキャッシュの大幅拡大と大幅改良、およびそれによる命令デコーダーの複数コア間での共用と強化であろう。

と言うわけで、そこそこ書けたので今回はここまでで。 GPU混載に対する予想はCPUとのリソース共用等について予想があるのだけれど、 既にintel自身からはAVX系の大幅拡張とベクトル化対応が発表されている。 これについては次回という事で。

う〜ん、息抜きのつもりで文章書いていたのだけれど、ちょっと一息入れすぎたね。 もうこんな時間か... 過去問での合格レベル達成に向けて、これからまた苦手の法令条文を憶えなくては。トホホ。



1)
といいつつ、最近のサーバー用CPUはマルチコア化の進行を進めすぎてシングルスレッド性能が下がりすぎてしまった点が 問題となっているようである。たとえば、OracleのT4ではT3に比べてコア数は逆に半減しており、 コア数を犠牲にしてでも劇的なシングルスレッド性能向上を目指しているそうだ。 PC用途ならば当然の発想と言えるが、サーバー用途でもシングルスレッド性能の重要性が再評価されているというのが時代のトレンドなわけだ。 いや、「マルチコア化は時代の流れである。」という意見も未だにあるから、 シングルスレッド性能の方がコア数より重要度が高いと考えているのは当サイトとOracleのCPUアーキテクトだけなのかもしれないけどね。 (ちなみに、Oracleのハードウエア共用によるシングルスレッド性能アップも、当サイトの過去のトレンド予想通り。 AMDに限らず各社で時代の流れとして対応が進むであろう。)