■後藤弘茂のWeekly海外ニュース■ 新CPUが目白押しのIntelサーバーCPUロードマップ

●サーバーCPUではWoodcrestから新アーキテクチャ

Intel Spring Analyst Meeting 2005で公開されたプレゼンテーション

　サーバー向けのIA-32系CPUでは、デュアルプロセッサ(DP)向けの「Woodcrest(ウッドクレスト)」が新アーキテクチャとなる。Woodcrestというコードネーム自体は、Intelが今年5月に開催した「Intel Spring Analyst Meeting」で、Paul S. Otellini(ポール・S・オッテリーニ)氏(President & CEO)がすでに公開している。

　Woodcrestの詳細はわからないが、デュアルコアでより低消費電力、高パフォーマンスで、パフォーマンス密度も高められるとされている。こうした特徴や時期から、デスクトップの「Conroe(コンロー)」やモバイルの「Merom(メロン)」と共通アーキテクチャだと推定される。

　IntelはCPU＋チップセット＋ETCで構成するプラットフォームを前面に押し出しつつある。Xeon DPは、NetBurst系デュアルコアの「Dempsey(デンプシ)」が登場する2006年第1四半期時点で、サーバーが「Bensley(ベンスレイ)」プラットフォーム、ワークステーションが「Glidewell(グライドウェル)」プラットフォームへと切り替わる。Woodcrestは両プラットフォーム上のCPUリフレッシュとして登場する。このことからFSB(フロントサイドバス)に互換性があることがわかる。ちなみに、DempseyからはFSBは667MHzと1,066MHzのサポートになる。自然な流れとしては、WoodcrestはFSB 1,066MHzの可能性が高い。

　Bensley/Glidewellからはチップセットが「Greencreek(グリーンクリーク)」、「Blackford(ブラックフォード)」系に代わる。Greencreek/Blackfordの最大の特徴は「Fully Buffered DIMM(FB-DIMM)」をサポートすること。元々のスケジュールでは、Greencreek/BlackfordとFB-DIMMはもっと早い段階で投入されるはずだったが、現在はデュアルコア投入と同期しており、FB-DIMMの市場投入もずれている。

　面白いのは、Intelが、まずDPシステムからFB-DIMMを浸透させようとしている。MPの大型システムはRegistered DIMMのまま残り、中間クラスからFB-DIMMへと変わるのは、ちょっと奇妙に見える。FB-DIMMの最大の効用はチャネル当たりのDIMM枚数&DRAM個数を増やして、高速化しても大容量メモリの搭載を可能にすることだからだ。

　しかし、最上位のメモリハブを使うようなシステムは、もともとFB-DIMMがなくても大容量&広帯域化ができている。そう考えると、DPクラスからFB-DIMMへ移行させるのはロジカルかもしれない。これによって、DDR2/3世代では、DIMMはUnbuffered DIMMとRegistered DIMM、FB-DIMMの3種類が併存するようになる。

CPUコア移行予想図 PDF版はこちら

●MP向けサーバーはマルチコアへ

　マルチプロセッサ(MP)向けCPUも目まぐるしく入れ替わる。現在のシングルコアXeon MPの次ぎに、90nmプロセスのデュアルコア「Paxville(パックスビル)」が登場、次に65nmプロセスの「Tulsa(タルサ)」が出てくる。Tulsaは、かなり以前からロードマップにあったコードネームで、Intelはもともと65nm世代ではデュアルコアをMPサーバーに投入しようとしていたようだ。

　さらにTulsaの次には、マルチコアの「Whitefield(ホワイトフィールド)」が次世代CPUとして控えている。Whitefieldというコードネームも、すでに公開されている。Whitefieldからは、CPUコアも新アーキテクチャへと変わる。

　IntelはCPUコアアーキテクチャの統一化を図っており、今後は、コア自体は共通だが、構成が異なるCPUをファミリ展開しようとしている。そのため、Whitefieldは、CPUコアのアーキテクチャ自体はConroeやMeromと共通だが、構成が異なるCPUだと推定される。おそらく、単純にCPUコア数が倍増するだけでなく、他の要素も異なる可能性が高い。例えば、キャッシュ構成やFSBが変わる可能性がある。Intelはこのあたりの世代から、IA-32とIA-64の両サーバープラットフォームの共通化を図り始める。となると、WhitefieldのFSBは、次世代アーキテクチャのIA-64系CPU「Tukwila(タックウイラ)」と共通の可能性もある。Whitefieldからはプラットフォームも「Reidland(リードランド)」に変わる。

Platform移行図 PDF版はこちら

●SossamanはMeromベースのサーバーCPUへの露払い?

　低消費電力のDPブレードサーバー向けCPUではYonahベースの「Sossaman」が加わっている。デュアルコアで動作周波数は2GHz、L2キャッシュは2MB、FSBは667MHz、Hyper-ThreadingとEM64Tはサポートしない。スペックを見てわかる通り、ほぼYonahそのままだ。違いは、デュアルプロセッサとメモリアドレッシング拡張「PAE(Physical Address Extention)」による16GBメモリのサポート。Processor Numberは「5048」と、かなり中途半端な数字がつけられている。

　Sossamanのポイントは、フィーチャが欠けてしまうこと。Xeon LV(Low Voltage)はEM64Tイネーブルの「Irwindale(アーウィンデール)」へと入れ替わったのに、Sossamanで32-bitアーキテクチャへと逆行してしまう。ただし、TDP(Thermal Design Power:熱設計消費電力)はIrwindale LVの55Wから、Yonahと同じ31Wへと下がる。

　Intelは、Sossamanについてパフォーマンス/ワットに集中したソリューションと位置づけているが、後続のMeromベースのDPサーバーCPUへの露払い的なイメージが強い。MeromではEM64Tはサポートされるはずで、その時点で再びフィーチャが揃うことになる。事実、IntelはSossamanについて、64bit LV Xeonと、次世代の電力最適化DPプロセッサの間のいいブリッジになると説明している。

●次世代IA-64のMontecitoは時期が後退

　IA-64 CPUでは「Montecito(モンテシト)」のスケジュールが後ろへずれ、現在は2006年第1四半期となっている。IntelがMontecitoで苦しんでいることがよくわかる。また、MontecitoのDP版として別ダイ(半導体本体)で開発されていた「Millington(ミリントン)」とそのLV版の「Millington LV」はロードマップから消えた。Montecitoと同ダイとなり、コードネームもMontecitoで統一されている。Montecitoのダイは巨大なので、経済的には少キャッシュの別ダイを用意した方がいいはずだが、今回はそうしない。2つのダイのバリデーションを行なう余裕がなくなったのかもしれない。

　IntelはMontecitoの次に65nmプロセスの「Montvale(モンベール)」へとシュリンク。その次のステップで、次世代マイクロアーキテクチャのマルチコアTukwilaへと切り替える。

　Tukwilaの時期とアーキテクチャは、まだ不鮮明だ。Intelは、Tukwila世代で斬新なアーキテクチャ拡張を提案したが、OEMベンダーの反対に遭ったこともあり、現在はより大人しいプランへと変更されているという。

　実際、Intelは、VLIW系アーキテクチャのIA-64に、動的スケジューリングやSMT(Simultaneous Multithreading)を搭載した場合の研究論文を発表しており、かなり大胆なアーキテクチャ変更も視野に入れていた可能性が高い。だが、その場合には、これまでIA-64で築き上げてきたコンパイラでの静的最適化が崩れてしまう可能性がある。そのため、本当に性能が発揮できるかどうかはわからなかった。ちなみに、Tukwilaでは5個よりも多い数のCPUコアを搭載するとされている。

　Intelは、前回のIntel Developer Forum(IDF)でプラットフォーム戦略を打ち出した。今後は、CPUではなくチップセットや周辺ハード&ソフトを含めたプラットフォームでアピールする方針だ。しかし、プラットフォームがあまりに多すぎてIntelのスタッフ自身も憶えきれないためか、まだコードネームが不明なプラットフォームも多い。また、上のプラットフォーム図では、煩雑になるため省いてしまったプラットフォームもある。ますます、わかりにくくなっている。

□関連記事
【8月8日】【海外】複雑になったIntelのモバイルCPUロードマップ
http://pc.watch.impress.co.jp/docs/2005/0808/kaigai201.htm
【7月28日】【海外】IntelデスクトップCPUロードマップアップデート
http://pc.watch.impress.co.jp/docs/2005/0728/kaigai200.htm

□バックナンバー

(2005年8月10日)

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