後藤弘茂のWeekly海外ニュース

2つのCPU開発チームに競わせるIntelの社内戦略




●チックタックモデルの2つのCPUチーム

 Intelの言う『チックタック(Tick Tock)』モデルは、本当にうまく行くのだろうか。チックタックモデルとは、2年置きにCPUのプロセス技術を革新(Tick)、その中間の2年置きにCPUマイクロアーキテクチャを刷新(Tock)する開発モデルのことだ。昨年(2007年)に45nmプロセスを導入し、今年(2008年)は新マイクロアーキテクチャ「Nehalem(ネハーレン)」を導入、来年(2009年)に32nmで、2010年に「Sandy Bridge(サンディブリッジ)」マイクロアーキテクチャを導入する。しかし、すんなり2年毎に交替するのか。もしかすると、どこかの時点で、デスクトップ&サーバー向けCPUと、モバイル向けCPUの2つのラインに再び分かれるかもしれない。それは、Intel社内のPC向けCPU開発チームの性格が、かなり異なるからだ。

 Intelは、現在、PC&サーバー向けのIA CPUの開発チームを2つ持っている。1つは、オレゴン州ヒルズボロ(Hillsboro)の開発チームで、Digital Enterprise Groupに属しており、Pentium III(P6)やPentium 4(NetBurst)アーキテクチャを開発した。もう1つは、イスラエルのハイファ(Haifa)にいるチームで、Mobility Groupに属しており、Pentium M(Banias)やCore Microarchitecture(Core MA)を開発した。IntelのIA-32系CPUは、この2つのチームが交代に開発する体制となっている。今年登場するNehalemはオレゴンチーム、2010年に登場するSandy Bridgeはイスラエルチームが担当する。

 この態勢の表向きの狙いは、4年サイクルと長いCPU開発期間をオーバーラップさせることで、新マイクロアーキテクチャCPUの投入を2年サイクルに短縮することにある。しかし、もう1つの意図は、2つのチームを社内で競い合わせることで、CPU開発を加速することにあると言われる。あるCPU業界関係者は、「オレゴン側は、イスラエルチームがCore Microarchitecture(Core MA)で成功したことで内心かなり焦っている。役職を見ても、イスラエル側が功績によって上がって来ており、今ではオレゴンと同格に並んでしまった。だから、オレゴンはNehalemに賭けて、非常に力を注いでいる。ここで失敗すれば、後がないからだ」と語る。

Intelのマイクロアーキテクチャサイクル
(※別ウィンドウで開きます)
PDF版はこちら

●よりパフォーマンスにフォーカスするオレゴン

 オレゴンの開発センターが力を注ぐNehalemは、実際にパフォーマンスモンスターだ。Intelが顧客に説明しているNehalemのパフォーマンスは、Core MA世代をはるかに上回る。デュアルプロセッサ構成で比較した場合、3GHzのクアッドコアXeon X5365(Clovertown:クローバタウン)に対して、クアッドコアのNehalem EP(Gainestown:ゲインズタウン)の性能は整数演算(SPECint_rate2006)で1.6倍以上、浮動小数点演算(SPECfp_rate2006)で2.4倍以上とされている。実際にパフォーマンステストをできるサンプルが出るまでは、本当の性能はわからないが、浮動小数点演算性能が異常に高いことは確かだろう。2.4倍という数値は、かなり異常で、大幅な拡張が予想される。

 ある業界関係者は、「これまで、Intel CPUの浮動小数点演算性能がなぜ悪かったのかは、社内でも議論になっていた。しかし、メモリボトルネックを考慮しないパーフェクトメモリでのシミュレーションを行なうと性能はちゃんと出る。大きなネックがFSBにあることは明らかで、そのために、Nehalemではそこを取り去るアーキテクチャを取った」と語る。Nehalemでは、FSBを介さずダイレクトにDRAMにアクセスし、メモリ帯域も極端に広げたことで、浮動小数点ユニットに充分なデータをフィードできるようになったというわけだ。もちろん、フィードするデータ量に見合うように、浮動小数点演算部にも拡張が加えられていることは間違いはない。

 こうしたNehalemのアプローチから見えてくるのは、依然としてパフォーマンスを第一に据えた考え方だ。ハイエンドデスクトップ&ワークステーションやサーバー向けにハイパフォーマンスを狙う。ただし、NetBurstまでのアプローチとは異なり、NehalemではTDP(Thermal Design Power:熱設計消費電力)とパフォーマンス効率にも考慮する。一定の電力の中で最大にパフォーマンスを発揮できるように狙う(ただし、現在出されている最初のNehalemのサンプルは外部電力供給が必要となっている)。それによって、同じ電力のサーバールームやデスクトップに、最大限のパフォーマンスを提供する。そうした発想に見える。「Nehalemの説明では、まずパフォーマンス。それから、TDPには収めるから大丈夫といった順番だ」とある業界関係者は語る。

 パフォーマンスを引き上げるには、より多くのトランジスタが必要となる。そのため、Core MAからNehalemでは、同じプロセス技術でCPUコアのサイズが1.5倍弱になった。CPUコアをより肥大化してパフォーマンスを上げる方向にある。

PenrynとNehalemのダイ比較
(※別ウィンドウで開きます)
PDF版はこちら

●電力に重点を置くイスラエル

 それに対して、イスラエル側のアーキテクチャは、電力削減によりポイントを置いている。少なくともCore MAまではそうであり、Core MAを開発したイスラエルのハイファデザインセンターの説明を聞く限り、今も軸線はぶれていないように見える。

 実際、イスラエルチームは、NetBurstからCore MAへの移行でも、CPUコアの規模は肥大化させず、ほぼ同じ程度の規模に抑えた。より電力消費を抑え、命令レベルの並列性を高めて、パフォーマンスは大きく伸ばした。その結果、パフォーマンス/消費電力は飛躍的に向上した。

 Core MAの弱点の1つは、命令フェッチから命令プリデコードの部分。ここの部分の帯域が、パイプラインのバックエンドの実行パイプラインと比べると細い。命令フェッチを拡張すれば性能を上げられることは当然わかっていても、消費電力とのトレードオフとなるため、そうはしない。性能と電力で、電力により振ったのがCore MAだ。無理をしてCPUコアを大きくして、電力を増大させるリスクを増やすより、機能を抑えても電力低減を目指す思想が感じられる。

 こうした思想自体は、Sandy Bridgeにも受け継がれているという。「Sandy BridgeではCPUコアは、それほど肥大化しないと聞いている。コア自体は、そこそこにとどめて、焦点はCPUコアの中よりも、むしろ他の部分に置いていると聞いている」とある業界関係者は言う。

 Sandy Bridgeでも、当然、浮動小数点演算パフォーマンスの拡張は続けられる。CPUにとって、効率を維持しながらパフォーマンスを上げることができる部分はそこだからだ。すでに、Sandy Bridgeについては1コア当たり28GFlops(4GHz時/SSE命令)という、浮動小数点演算パフォーマンスの数字がレポートされている。浮動小数点演算ユニットの相対的な面積は小さくなっているため、32nmプロセスのSandy Bridgeでは、浮動小数点演算ユニット自体ではNehalemから極端な肥大化は招かないと推測される。

 問題は、むしろ、増えた性能に見合うだけのオンチップとオフチップの帯域の確保で、そのために、Sandy Bridgeはメモリバスや内部バスに工夫をこらす必要がある。

●CPUコアを大きくしないでパフォーマンスを引き上げる

 CPUコアを小さくとどめてパフォーマンスを引き上げるという思想は、イスラエルチームが注力している仕様である「ターボモード」にも見て取れる。ターボモードは、CPU内外のさまざまな条件の変化に応じて、CPUコア単位でパフォーマンスをブーストする技術だ。それによって、システムの冷却能力の枠内で、効率的にパフォーマンスを高める。Intelでハイファデザインセンターを担当するIntelのRon Friedman(ロン・フリードマン)氏(Vice President, General Manager, Mobile Microprocessors Group)は、ターボモードによって、ほとんどのケースで20%を超えるパフォーマンス向上が得られるだろうと示す。

 ターボモードのポイントは、CPUのトランジスタをほとんど増やすことなくパフォーマンスアップを得られることにある。消費電力的に見ると安全なパフォーマンスアップであり、イスラエルチームは以前からこのモードの利点をIntel社内で力説していたという。

 CPUの平均消費電力の低減を強調する点も、イスラエルチームのポイントだ。モバイルでは、TDPと同様に平均消費電力の低減が重要となるため、モバイル部門に所属するイスラエルチームとしては当然だが、この点はオレゴンチームと大きく異なる。「オレゴン側から平均消費電力を重視するという説明は聞いたことがない」とある業界関係者は言う。オレゴン側が、サーバー&デスクトップ部門に所属していることを考えると、これも当然かもしれないが、イスラエルチームはサーバーでも平均消費電力が重要だと主張する。

 「今日、サーバーファームにとって最も重要な指標となっているのは、コンピュート密度だ。つまり、一定の電力供給と冷却の中で、どれだけ多くのコンピューティングをパックできるかが重要となっている。

 もし、より少ない電力でコンピューティングできるのなら、サーバールームにより多くのコンピューティングパフォーマンスをパックできることになる。サーバーファームにとっては、電力コストはますます重要になっており、電力消費が少なければ、冷却能力も増やさなくて済むため、より多くの電力をセーブできる。

 問題は、サーバーとサーバーファームの平均消費電力をどう定義するかについて、まだ議論の最中で、コンセンサスが得られていないことだ。定義のための作業は行なわれているが、依然として業界標準の定義はできていない」(Friedman氏)

 論点は明確で、イスラエル側は、サーバーCPUであっても平均消費電力の低減が重要となると見ている。逆を言えば、次々世代のサーバーも担うSandy Bridgeも、平均消費電力にかなりフォーカスしていると予想される。

ターボモードのポイント

●GPUコアの統合に対する考え方が異なる

 CPUへのGPUコアの統合についての考え方も、オレゴンとイスラエルで大きく異なる。オレゴン側は、当面は同パッケージに収めればOKと考えているようだが、イスラエル側はオンダイ(On-Die)に統合しないと意味が薄いと信じている。それは、オンダイ統合でなければ電力削減の効果が少ないからだ。

 イスラエルの出身である、IntelのShmuel(Mooly) Eden(ムーリー・エデン)氏(Vice President, General Manager, Mobile Platforms Group, Intel)は、昨年9月のIDFの際に次のように語った。

 「全体的には、モバイルテクノロジでは統合化はI/Oを減らすことで消費電力とフットプリントを減らす利点がある。また、CPUとグラフィックスをタイトに統合できれば、(GPUとCPUの)実行ユニットを、それぞれ相互に使うこともできるようになる。多くの面で、統合は理にかなっている。

 しかし、注意深くならなければいけないことも確かだ。まず、マーケティング上(の統合)と、真の統合を区別する必要がある。マルチチップパッケージで(GPUをCPUパッケージに)入れたとしよう。それはチップの実装面積を減らすが、革新的だろうか? ノーだ。では、同じシリコンに(CPUとGPUを)入れた場合は? それは革新だ。

 最終的には、統合は理にかなう。だから我々は、統合は正しい方向だと信じている。全般的に言えば、次第に統合へと進んで行くだろう」

 この時点では、まだオレゴン開発のNehalemでのGPU統合CPU「Havendale/Auburndale」が、CPUとGMCH(ノースブリッジチップ)の2つのチップを1パッケージに封止したMCMであることはわかっていなかった。しかし、今振り返ると、Eden氏のこの言葉は、オレゴン流のGPU統合への批判となっている。シリコン上での統合でないのなら、マーケティング上の統合であると示唆しているからだ。オレゴン側のアプローチは革新的ではないと言っているように聞こえる。

Havendale/Auburndaleシステムアーキテクチャ
(※別ウィンドウで開きます)
PDF版はこちら

●問題は統合化のタイミングの難しさ

 それに対して、イスラエルチームは、CPUへのGPUコアの統合を実際に設計した経験がある。キャンセルになった「Timna(ティムナ)」だ。Timnaは、Eden氏の指揮の下で、Intelイスラエルの開発チームが開発したPentium III系の統合CPUで、GPUコアとDRAMコントローラを内蔵していた。

 「CPUとGPUの統合を成功させるには、正しい時に正しい技術で行なわなければならない。最初にGPUを統合したCPUは何だったかを思い出して欲しい。それはFUSIONではない。CPUとGPUを統合した最初のチップは“Timna”だった。

 Paul(Paul S. Otellini(ポール・S・オッテリーニ)氏(President & CEO))は、Timnaについて2つのミスがあったと言った。1つはTimnaの開発を始めたこと、もう1つはTimnaをやめたことだ。なぜなら、Timnaがキャンセルされたのは、GPUの統合がうまく行かなかったからではないからだ。GPU統合自体は素晴らしく、うまくいった。それなのに、Timnaが出荷されなかった理由は、RDRAMインターフェイスを統合したことだった。RDRAMは高価過ぎたからだ。

 Timnaの経験があるから、CPUとGPUの統合は、私にとって新しい話ではない。だから、統合には制約がつきまとうことを理解している。例えば、CPUを2年毎にリフレッシュし、そしてGPUを6〜7カ月毎にリフレッシュしたいとする。すると、(CPUの開発サイクルのためにGPUアーキテクチャが)凍結される期間が長くなってしまう」

 Eden氏が指摘しているのは、CPUへの機能の統合では、適切なタイミングを選ぶことが難しいという点だ。Timnaの場合は、統合したDRAMコントローラがメインストリームにならなかったために失敗した。このつまづきがなければ、CPUへのGPUコアの統合はもっと早期に浸透していたかもしれない。短サイクルで進化を続けるGPUコアについても、適切なタイミングで統合しないと、統合したGPUコアの機能が時代遅れになるという失敗を犯しかねない。

 ある業界関係者は、IntelのGPU統合は最初はMCMだが、その先ではシリコン上でのGPU統合を計画していると言う。Timnaの失敗を経験したイスラエルが、Sandy BridgeでGPUを統合するとしたら、合理的な方法は、CPU設計をある程度モジュラー化して、GPUコアの差し替えを容易にすることだろう。

 ある業界関係者は、Sandy Bridge世代では、内部ネットワークが簡単にコアを増やせるようになっているという。GPUのような異種コアも含めて、容易に統合できる構造と言われる。Sandy Bridgeが、CPUの各ブロックの接続のために広帯域のリングバスを備えるという情報は、これに符合する。Cell Broadband Engine(Cell B.E.)もCPUコア間の接続にリングバスを採用しているが、接続するユニットが一定以上に増えた場合には、設計上はリングバスが合理的な選択だ。クロスバースイッチより、はるかに設計が容易になるからだ。そのため、リングバスならコア数の増減にも、設計上は対応しやすい。

統合型CPUとして開発されたTimna
(※別ウィンドウで開きます)

●技術構想がしっかり定まっているイスラエルセンター

 イスラエルのハイファデザインセンターが開発したCPUマイクロアーキテクチャは、Banias、Yonah、Meromと連続性が強い。飛び飛びに革新するのではなく、インクリメンタルに技術を加えているように見える。あるCPU業界関係者は「しっかりとできあがったパフォーマン効率の高いCPUの技術構想があり、その技術要素を、1つ1つ段階的に実装している印象だ」と語る。

 パフォーマンス/パワー効率を高めるCPU設計のアイデアを煮詰め、将来的に、どういったCPUを開発するのか、かなり固まったビジョンを持っているのかもしれない。そして、その技術の中から、各世代のプロセス技術によるトランジスタバジェットに合わせて実装している可能性が高い。

 だとしたら、ハイファデザインセンターの次のマイクロアーキテクチャ「Sandy Bridge」は、その延長にあると推測される。Banias、Yonah、Meromと積み上げた先のマイクロアーキテクチャがSandy Bridgeになる。ある業界関係者は「Sandy Bridgeは、最初に元になるアイデアを聞いた時から今までで、ほとんど内容が変わっていない」と言う。路線は、すでに、かなり前から決まっていたと考えられる。

 Sandy Bridgeは、もともとはヘブライ語のコードネーム「Gesher(ゲッシャ)」で呼ばれていた。GesherからSandy Bridgeへと変わったのは、技術的な内容の変化があったからではなく、名称だけだという。IntelはCPUコードネームから、ヘブライ語を排して英語に揃えようとしているように見える。これは、イスラエル開発のCPUのコードネームから、イスラエル臭を取ろうとしているのかもしれない。

 Gesherはヘブライ語で「橋」の意味で、従来のような地名ではない。そのため、同マイクロアーキテクチャのCPUファミリには「Bridge」がつけられることになったという。Gesherだけが地名コードネームでないのは、橋であることに意味があるからだと言われる。このことは、Sandy BridgeではCPUコア自体ではなく、CPUコアの接続や制御にフォーカスが当てられている可能性を示している。

●タイプが異なる2つのセンターが並立

 性格が異なるIntelの2つのCPU開発センター。その違いの根本は、それぞれの人材のタイプの違いにあるのかもしれない。

 「オレゴン側のアーキテクトは、クセのある、ちょっとエキセントリックな天才肌の雰囲気の人物が多い」とあるCPU業界関係者は言う。IDFなどで表に出て来るアーキテクト達を見ても、そういった印象を受ける。それに対して、イスラエル側のアーキテクトは、どちらかと言えば、もっと普通の雰囲気の人物が多いように見える。これは極めて主観的な感想だが、同じような印象を受けたと語るIntel関係者もいた。

 実際、オレゴンのアーキテクトからは、Intelを辞めた後にCPU開発裏話の本を書いたり、Webで自分の業績をぎりぎりのところまで明かす人物が出るが、イスラエルからはそうした話は聞こえてこない。「イスラエルのチームは非常に統制が取れていると聞く」とある業界関係者は語る。

 また、イスラエル側のR&Dチームからは、論文もあまり発表されない。「論文を出したらアイデアを知られてしまう。我々は、そうしたことは好まない」とEden氏はその理由を説明する。これは、学会や学術誌に論文を発表すること自体が業績と考える、米国の研究者の考え方とはかなり異なる。

 こうして見ると、同じIntelのCPUを開発していても、オレゴンとイスラエルでは、文化も考え方もかなり異なることがわかる。当然、そこから産まれてくるCPUマイクロアーキテクチャも異なる。

 となると疑問は、本当に両チームのCPUが、2年毎に、モバイルからハイエンドまで全てをカバーして入れ替わってゆくのだろうかという点だ。これは、Nehalemのモバイルと、Sandy Bridgeのハイエンドがそれぞれの市場にフィットするかどうかという点にかかって来る。もしかすると、サーバーではNehalem系が残り、モバイルではSandy Bridgeへと切り替わるといった併存状態になるかもしれない。

□関連記事
【1月22日】【海外】PCからノースブリッジが消える日
http://pc.watch.impress.co.jp/docs/2008/0122/kaigai411.htm
【2007年10月11日】【海外】Intel NehalemとAMD FUSION両社のCPU+GPU統合の違い
http://pc.watch.impress.co.jp/docs/2007/1011/kaigai392.htm
【2007年10月5日】【海外】Intelが目指すNehalemでのGPUとCPUの統合
http://pc.watch.impress.co.jp/docs/2007/1005/kaigai391.htm
【2007年9月21日】【元麻布】液浸露光技術で32nmプロセスを目指すIntel
http://pc.watch.impress.co.jp/docs/2007/0921/hot506.htm

バックナンバー

(2008年1月29日)

[Reported by 後藤 弘茂(Hiroshige Goto)]


【PC Watchホームページ】


PC Watch編集部 pc-watch-info@impress.co.jp ご質問に対して、個別にご回答はいたしません

Copyright (c) 2008 Impress Watch Corporation, an Impress Group company. All rights reserved.