■後藤弘茂のWeekly海外ニュース■ 電力効率の向上にフォーカスするIntelの研究開発

●シミュレーションでは39%の電力アップで45%の性能アップ

　Intelでプロセッサ研究を担当するMicroprocessor Labは、電力効率を高めることで、パフォーマンス/電力を画期的に高めるCPUアーキテクチャ「Power AwaReness thRough selective dynamically Optimized Traces(PARROT)」を発表している。PARROTは、まだ研究段階のアーキテクチャだが、現在のような消費電力が最大の壁となった時代にもっとも適したアプローチの1つと推測される。

　では、PARROTアーキテクチャによって、CPUはどれだけの効率化が図れるのだろう。PARROTでは、頻繁に使うコード部分(ホットコード)に対して、アグレッシブな最適化を行なう。それによって、IPC(1サイクルで実行できる命令数:instruction per cycle)を高め、実行する内部命令(μOPs)数を減らす。また、マイクロアーキテクチャ上の処理をできる限り再利用することで、無駄を省く。その結果、パフォーマンスを高めつつ、消費電力の低減を図ることができるようになる。

　例えば、PARROTのプレゼンテーションで示された例だと、28個のμOPsのコードが10個のμOPsのコードに削減できるという。その分、実行コアでの実行時間が短くなって性能が上がり、実行コアの負担も減るため消費電力も下がるわけだ。

PARROTのオプティマイゼーション例

　また、論文ではPARROTを適用したアーキテクチャのシミュレーションも示されている。それによると、フロントエンドの命令帯域が4wide(4命令/サイクル)の既存アーキテクチャにPARROTを適用した場合には、電力消費の増大を4%に抑えながらIPCを17%向上させることができるという。さらに、PARROTの適用に合わせて命令帯域を8wideに広げた場合には、電力の増大は39%で、IPCの向上は45%になるという。

　従来は、アーキテクチャ拡張によって電力効率は下がる傾向にあった。しかし、シミュレーションを見る限り、PARROTでは電力効率は画期的に向上することになる。

PARROTを適用したアーキテクチャのシミュレーション

●Meromでは4wideへと命令帯域を広げる?

　ちなみに、このプレゼンテーションで興味深いのは、現在のプロセッサアーキテクチャの例である一番上の「N」のボックスのところに「Merom-like」と書かれていることだ。「Merom(メロン)」は、Intelが2006～7年のモバイルCPU向けに、開発している次世代CPUコアアーキテクチャのコードネーム。図の「N」はスタンダードなモダンCPUのリファレンスで、4wide、スーパースカラ/スーパーパイプライン/out-of-orderのマイクロアーキテクチャとなっている。図を見る限り、Meromはそうしたアーキテクチャを取るようだ。

　Meromが4wideだとしたら、今の世代のCPUとは、フロントエンドの命令のフェッチ/スケジューリング/イシュー幅が違うことになる。フロントエンド帯域は、NetBurstは実質3wide(デコード済みのμOPsの場合)、Pentium Mも同様だと見られる。そうすると、Meromは現行CPUよりも、命令帯域が広いCPUということになる。

　現行CPUで命令帯域が3wideに限られている理由はスケジューリングのためで、3wide分以上の命令並列性を実現するのが難しいからだ。4wideで十分に稼働させるためには、今のCPUと比べて、より多くの命令を並列化できなければならない。そのため、Meromでは、スケジューリングに関わる部分が拡張されると推測される。ちなみに、IA-32ではデコードが最大のボトルネックだが、これについてはIA-32からμOPsに変換した状態でキャッシュしておくことで一応は解消できる。

　ちなみにIBMのPowerPC 970系CPUは、内部では4命令+1分岐命令/クロックの、4～5wideのコアを持つ。また、ソフトウェアでより広域に対してスケジューリングを行なうTransmetaは、「Efficeon」で最大8wideに並列化する。3wide以上は、すでにトレンドになりつつある。

　このプレゼンテーションからは、PARROTがMerom世代には適用されないこともわかる。PARROTが実装されるとしたら、それはMerom(2006年末)/Merom+(2007年)系アーキテクチャの次以降になりそうだ。

●似ているPARROTとTransmetaのCMS

　PARROTのポイントは、ホットコードに対する重点的な最適化にある。しかし、この手法は、ダイナミックコンパイラではすでに知られている。その意味では、PARROTは「ダイナミックコンパイラ的な最適化手法を、ハードウェアに取り込む」と形容してもいいかもしれない。

　実際、PARROTと似た技術をソフトウェア層に実装した先例なら、CPUの世界でも、身近にある。それはTransmeta系CPUで、同社のアーキテクチャでは、ダイナミックコンパイラを含む「コードモーフィングソフトウェア(CMS:Code Morphing Software)」でCPUネイティブ命令セットへの変換とスケジューリングを行なっている。その際に、EfficeonではPARROTと似通った最適化を行なっている。CMSがコード上のホットスポットを見つけて、多段階の最適化をかけて、再スケジュールやデッドコードの削除、トレースパスの最適化などを行なう。PARROTの論文を見たあるCPU業界関係者も、真っ先にアイデアがTransmetaに似ていると指摘した。また、PARROTのプレゼンテーションの中にも、TransmetaのCMSを関連するソフトウェア技術として挙げているものがある。

　この類似性について、TransmetaのDavid R. Ditzel(デビッド・R・ディツェル)共同創業者兼副会長兼CTO(Co-Founder, Vice-Chairman and CTO)は次のように語る。

　「PARROTと同じような技術は、我々はすでに以前から実装している。PARROTが、我々のアーキテクチャに似ているのは不思議ではないだろう。Intelは常に我々からコピーするからだ(笑)。我々は、これ(ホットスポットにアグレッシブな最適化をかけること)が当然の進化の方向だと考えている」、「しかし、我々(のCMS)とIntel(のPARROT)では手法に大きな違いがある。Intelは、(最適化エンジンを)ハードウェアで実装しようとしているようだが、われわれはソフトウェアで実装した。その結果、我々はCPUのトランジスタ数を減らし、電力消費も減らした。Intelがハードウェアで実装すれば、その分、トランジスタ数が増え、電力の消費では不利になる」

　それに対して、IntelのGelsinger氏は次のように答える。

　「基本的にはデイブ(Ditzel氏)には同意しない。私の意見はシンプルだ。我々は、ハードウェアとソフトウェアの両方を非常に重要だと見ており、両者の協調を常に考えている。ハードウェアの方がソフトウェアより(実装に)適した部分と、ソフトウェアの方が適した部分がある。PARROTはホット実行とコールド実行を備える電力効率の高いマイクロアーキテクチャだ。このテクニックと協調することで、ソフトウェアスケジューラやコンパイラもずっとパワフルになるだろう。ある意味で、デイブはフレキシブルなハードウェアを彼が持たないことを、正当化しようとしたのだと思う」

　PARROTのような高度な最適化についても、Transmetaのように全てをソフトで実装するより、ハードに実装した方が効果的だと主張しているわけだ。実際、PARROTの場合は最適化やトレース生成は完全にバックグラウンドで行なわれる形で、Transmetaのアプローチとは異なりフォアグラウンドのパイプラインのサイクルを消費しない。

　Transmetaは、スケジューラだけでなく命令セットアーキテクチャ(ISA)もソフトウェアであるCMSに実装することで、プロセッサのハードとソフトのパーティショニングをソフト寄りに変えた。それに対して、Intelは、ダイナミックコンパイラ的なテクニックを取り込むことで、よりハード寄りにパーティショニングを切り直そうとしているように見える。一方で、コンパイラなどソフトウェア側が、PARROTのホットパスを意識することで、より効率的になることも示唆している。

　ホットスポットに対する最適化をハードウェアで実装するPARROTのアイデアは突然生まれてきたわけではない。大抵のCPUアーキテクチャがそうであるように、類似の研究がほかの研究機関でも同時多発的に行なわれている。イリノイ大学の「rePlay: A Hardware Framework for Dynamic Optimization」などがPARROTと似通ったハードウェアベースの最適化アプローチだ。また、トレースパスの最適化の手法についても、いくつもの論文が出ている。同じようなことを考えている研究者が少なからずいるわけだ。PARROTやrePlayのようなアプローチは、CPU業界の一種の研究トレンドになりつつあるのかもしれない。

●電力効率を高めることがCPUアーキテクチャのフォーカスに

　Intelの内部でも、PARROTへの流れが見える。PARROTの論文は、Pentium Mを開発したイスラエルIntelのMicroarchitecture Research Labの研究者から発表されている。このことから、Pentium Mアーキテクチャの研究の延長線に、PARROTがあることが推測できる。

　もっとも、Intel幹部達は、PARROTはまだ研究途中のアーキテクチャで、実装については未定だと強調する。

　「我々は、PARROTについてはまだどんな決定も下していない。PARROTは、まだMicroprocessor Labでの研究段階のものだ。だから、PARROTだけをあまり強調したくはない」(Gelsinger氏)

　PARROTが次のCPUアーキテクチャに採用されると決まっているわけではないと、慎重にクギを刺している。実際、PARROTのプレゼンテーションにあったように、MeromはPARROTではないと見られる。しかし、最近インタビューしたIntelの開発系幹部は、いずれもPARROTについて熟知していた。このことから、PARROTは、Intel内部でも真剣に受け止められていると見られる。

　もっとも、PARROTだけがIntelの持ち駒ではないだろう。

　「PARROTは確かに、我々のアイデアのひとつだ。でも、全てではない」とGelsinger氏は、IntelがPARROTのほかにも電力効率を高めるためのさまざまな技術を研究していることを示唆する。Gelsinger氏は例として、CPU設計時の電力消費をより正確にアナライズするツールなどを挙げた。これは、プリンストン大学の研究者がIntelの研究者と共同で発表した論文「Wattch: a Framework for Architectural-level Power Analysis and Optimizations」で説明されている「Wattch」テクノロジを指すと見られる。

　ひとつ明確なのは、IntelのCPUアーキテクチャの研究開発が、今は電力効率を高めることに完全にフォーカスされていることだ。

　「PARROTに見られるアイデアは、我々の現在のリサーチ活動全体を支配しているものだ。それは、電力効率(Power Efficiency)だ。過去には、我々はマキシマムパフォーマンスを目指してプロセッサを設計していた。しかし、これからはオプティマムパフォーマンスのために設計をする。全てがシフトした。PARROTはその一例だ」とGelsinger氏は言う。

　もうひとつ見えてきたことは、IntelがCPUコアにより複雑な機能を加えることで、電力効率の向上を図ろうとしていることだ。CPUコアをシンプルに保つことで、電力効率を高めようという流れではなさそうだ。今のところ、IntelはシンプルCPUコアでマルチコアCPUを実現するアプローチの開発を行なっている形跡が見えない。

　ちなみに、シンプルなCPUコアを多数搭載するマルチコアCPUは、CPU業界のトレンドのひとつになりつつある。特にエッジサーバーやネットワーク機器などの用途が有望だと見られている。Sun Microsystemsは開発中の「Niagara(ナイアガラ)」でそうした方向を目指している。Compaq ComputerもAlphaアーキテクチャベースの「Piranha(ピラニア)」と呼ぶリサーチCPUプロジェクトを以前発表している。IBMもソニー・コンピューターエンタテインメント(SCE)、東芝と共同開発している「Cell」プロセッサをそうした用途に応用する可能性がある。マルチコア化を契機に、CPUのマイクロアーキテクチャは、再び多様化しつつあるのかもしれない。

PARROTのパイプラインコンセプト PDF版はこちら

□関連記事
【11月8日】【海外】Intel CPUの未来が見えるPARROTアーキテクチャ
http://pc.watch.impress.co.jp/docs/2004/1108/kaigai132.htm
【11月5日】【海外】ポラックの法則を破るためのマルチコア
http://pc.watch.impress.co.jp/docs/2004/1105/kaigai131.htm
【10月30日】【海外】3ステップでマルチコア化を進めるIntelのサーバー&ワークステーション系CPU
http://pc.watch.impress.co.jp/docs/2004/1030/kaigai130.htm
【10月22日】【海外】デュアルコアCPU“Smithfield”は来年第3四半期に登場
http://pc.watch.impress.co.jp/docs/2004/1022/kaigai128.htm
【6月9日】【海外】AMDが2005年にデュアルコアCPUを投入
http://pc.watch.impress.co.jp/docs/2004/0609/kaigai095.htm

□バックナンバー

(2004年11月9日)

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