IntelはCore i=Nehalem(ネハーレン)マイクロアーキテクチャの開発に5年をかけた。スタートは、2003年で、まずサーバーとモバイル(ノートPC)を優先とすることが決められた。そして、CPUコアはどのアーキテクチャをベースにするのかが検討されたという。この時点では、「Northwood(ノースウッド:130nm版Pentium 4)」をベースにするプランと、フロスムクラッチ(ゼロから)でマイクロアーキテクチャを新開発するプランもあったが、最終的に「Core Microarchitecture(Core MA)」と同じ「Pentium Pro/II/III(P6)」パイプラインを拡張するプランに落ち着いた。

　続く2004年には、CPUコア数とベクトル命令拡張、SMT(Simultaneous Multithreading)の実装について、どの組み合わせが最適かが検討された。検討のすえ、ベクトル命令拡張は落とされた。

　次に初期のゴールとして、“マルチコアタックス”を取り去ることが定められた。これは、CPUコア数が多いCPUの方が、動作周波数が低くシングルスレッド性能が低くなるというタックス(負担)だ。その解消のためターボモードの採用が決められたという。

　こうした段階を経てNehalemは、今の姿になった。

　IntelはNehalemの開発が2003年からスタートしていたことを明かした。これは、IntelがPentium 4の拡張として開発していた「Tejas(テハス)」のキャンセルを発表した2004年春よりも前の段階で、すでにIntelがCPU開発の方向を変更していたことを示している。

　Intelは、もともと、Tejasの開発と平行して、シングルコアの性能を追求していたと見られる初代Nehalemの開発を2001年にスタートしていた。これは、Intelが2002年に自社Webサイトで公開した当時のNehalemのアーキテクトDoug Carmean氏へのインタビュー記事「Oral History Interview With Doug Carmean」で明らかにされた。

　しかし、IntelはTejasキャンセルを明かすよりも前の2003年には方向を転換、この旧Nehalemをキャンセルしたようだ。そして、新Nehalemでは、マルチコア化を前提として、より電力効率の高いCPUコアの選択に入った。おそらく、Tejasのキャンセルも、2004年春より早い段階で決まっていた可能性が高い。Intelはこの当時、x86(IA-32)系CPUにIA-64命令デコーダも組み込んで、IA-32/IA-64両互換のデュアルデコードCPU(IA-64 VLIW命令も分解してオペレーション単位でOut-of-Order実行する)をもたらすことを計画していたと言われる。しかし、そのプランも方向転換の中で消えていったと見られる。

　とはいえ、Nehalemの仕切り直し出発が行なわれたのは、2003年のそれほど早い時期ではなさそうだ。なぜなら、2003年にアーキテクチャチームは、NehalemのCPUコアのベースにするアーキテクチャの方向を決めただけで終わっていたからだ。

CPU移行計画の変遷(PDF版はこちら)

　2003年に、Intelのオレゴン州ヒルズボロの開発チームは、仕切り直し版NehalemのCPUコアの“選定”を行なった。この時点でのCPUコアの選択肢は次の3つだったという。(1)Northwoodパイプラインの拡張、(2)P6パイプラインの拡張(Core MAと同じ)、(3)フロムスクラッチのパイプライン開発。つまり、ゼロから作る(フロムスクラッチ)か、Pentium 4ベースか、Pentium IIIベースかの3択だった。

マイクロアーキテクチャの選定

　また、CPUコアアーキテクチャの選定に先立って、サーバーとモバイル(ノートPC)にフォーカスすることも決まっていた。そのため、CPUコアには、シングルスレッドで高パフォーマンスでありながら、低コストかつ低消費電力であることが求められた。サーバーでも、マルチコア化を前提として、コア当たりの電力と実装コストを下げることが要求されていた。

　また、開発チームには、開発にかかるエンジニアリングコストも最小に抑えることも要求されていたという。今振り返ると、その理由も明瞭にわかる。Intelは、CPU開発の転換点となった2003～2004年前後に、今につながる多数のプロジェクトを立ち上げているからだ。そのため、巨人Intelですら、開発リソースが手薄になったと推定される。

　具体的には、旧Nehalem開発チームは、新Nehalem開発チームと「Larrabee(ララビー)」開発チームに分かれた(旧NehalemのアーキテクトCarmean氏はLarrabeeのリードアーキテクト)と言われている。そして、キャンセルになったTejasの開発チームは、Atom(Silverthorne:シルバーソーン)開発チームになったと推測されている。Atomの開発チームは、旧Motorolaから引き抜かれたPowerPC開発チームが主体となっており、同チームのリーダーだったMark McDermott氏はTejasの担当者と報道されていた。逆算すると、Silverthorneは、開発スタートから製品出荷まで4年から4年半かかったことがわかる。

CPUアーキテクチャ開発サイクル(PDF版はこちら)

　IntelはNehalemのコアとして、Northwoodは検討したが、同じPentium 4でも90nm版のPrescott(プレスコット)は候補に挙げなかった。今年(2010年)2月に米スタンフォード大学の公開講義EE380で「Key Nehalem Choices」と題した講演を行なったIntelのアーキテクトGlenn J. Hinton氏(Intel Fellow, Intel Architecture Group, Director, IA-32 Microarchitecture Development, Intel)は、PrescottとNorthwoodでは(電力)効率が大きく異なったと説明している。Hinton氏によると、NorthwoodはP6と同じように効率がよかったが、パイプラインを変更したPrescottの効率は悪かったと言う。

　NorthwoodとPrescottの最大の違いはパイプラインの深さだ。Northwoodは20ステージ(分岐予測ミスパイプ/x86命令デコードステージも含まない)。それに対してPrescottは31ステージと、約50%パイプラインが深くなっている。

　パイプラインが深くなると各ステージのデータを保持するラッチ回路が相対的に増え、ラッチオーバーヘッドが大きくなる。下はIBMが2005年の「Hot Chips 17」でのチュートリアルセッション「Power-Aware Microarchitectures Design, Modeling and Metrics」で示したチャートだ。ハイパフォーマンスCPUでは、ラッチ部分の電力消費の比率が極めて大きいことがわかる。そして、パイプラインが深くなると、下のチャートの赤で示されたラッチ部分が相対的に肥大化して行く。つまり、ラッチオーバーヘッドが大きくなる。

ハイパフォーマンスのCPUはラッチオーバーヘッドが大きくなっていく

　この他にもパフォーマンス効率に対する影響は大きい。パイプラインのレイテンシが伸びるため、CPI (Clock per Instruction)も下がる。また、命令スケジューリングによりリソースが必要になるなど効率が悪くなる。こうした効率性の問題から、Prescottは落とされたと見られる。

　Hinton氏らのチームは、3つの選択肢全てを検討した。それぞれに利点があったという。

　まず、パフォーマンス面ではフロムスクラッチで開発した場合が一番高くなる可能性があった。また、NorthwoodはP6拡張コアよりもパイプラインが深い分だけ、同じトランジスタスピードでも高周波数にできる(Core MAは14ステージ)。シングルスレッドのパフォーマンス面では、P6パイプラインはそれほど有利ではないと見られていた。

　しかし、最終的にIntelはP6パイプラインの拡張を選んだ。その理由は、コア当たりの電力消費が他の選択肢より小さく、また、コアサイズも他の選択肢より小さかったからだという。サーバーでは、CPUコアがより低電力になるために、8コアでも相対的に小さな消費電力で済む点が魅力だったようだ。また、フロムスクラッチ開発と比べると、トータルのエンジニアリングの労力も少なくて済む。さらに、新パイプラインを開発する場合と比べると、ソフトウェアの最適化についても、これまでと一貫性を保てる点で利点があるという。

　IntelはフロムスクラッチでCPUアーキテクチャを大きく変えれば、シングルスレッドパフォーマンスをもっとラディカルに上げることも可能だったと考えている。しかし、大がかりな設計エンジニアリングには時間がかかる。また、開発と修正に追われ、設計をチューニングして磨き上げることに時間がかけられないという。

Bloomfieldのダイ(PDF版はこちら)

　これは重要なポイントだ。x86 CPUの場合は、複雑であるため、最終段のパフォーマンスチューニングと磨き上げに時間がかかるからだ。2004年に同じスタンフォードの公開講義で「Things CPU Architects Need To Think About」という講演を行なったP6のアーキテクトBob Colwell(ボブ・コールウエル)氏が、その事情を説明していた。それによると、IA-32のパフォーマンス向上は「ゾウを急坂に押し上げるようなもの(Pushing Elephants up Steep Hills)」で、無理な高速化により、アーキテクチャ上の脆弱性が増していると指摘していた。

　また、Carmean氏も、Pentium 4の開発ではテープアウトの1年前という、設計の後半になって、パフォーマンスに大きな問題があることが判明。20人の開発者が6カ月籠もりきりになって問題解決に集中したと説明していた。

　Colwell氏によると、CPU開発では正確なパフォーマンス分析ができる設計段階になって問題が発見されるケースが多いと言う。その場合、設計が進みすぎていて本質的な修正ができず、小手先の修正を加えることになる。しかし、その結果、複雑さの上に複雑さを重ねることになり、別な問題を招いてしまうことがある。例えば、1つの問題箇所を直すと、2つの問題が発生するようなことになるという。

　このことは、x86系CPUを設計しようとしたら、既存のパイプラインをベースにする方が安全であることを示している。ハイパフォーマンスx86系CPUは、それだけ複雑でやっかいだ。Hinton氏も、NehalemについてP6ベースの、よりシンプルな設計を選ぶ利点として、その点を指摘していた。P6ベースにした場合は、パフォーマンス的には効率的でない部分もある。しかし、設計にかかる労力が相対的に少ないため、エンジニアリング段階で、チューニングにより時間をかけることができるという。

　こうしたトレードオフを考慮して、(フロムスクラッチ設計で)ある程度(10～20%)のシングルスレッドのパフォーマンス向上が得られる可能性を諦めることにしたと言う。

Nehalemアーキテクチャのブロックダイヤグラム(PDF版はこちら)