Nehalemの解説＠マイコム大原せんせ

PC CPU

　http://journal.mycom.co.jp/articles/2008/04/10/idf09/index.html
　最近大原センセの解説分かりやすくて好き。



　まずフロントエンドのFetch/Decodeある(Photo06)。従来は4命令/Cycleの

　デコーダにMacroFusionやLoop Stream Detectorを組み合わせる形で実装されて

　いたわけだが、このMacroFusionには色々と制限が多かった。以前こちらでちょっと

　触れている通り、MacroFusionの対象はCMP+JCCかTest+JCCに限られていたが、

　Nehalemではこのバリエーションが増やされ、かつ64bitモードでも動作するようになった
　当然とはいえ64bit MacroFusionキター。
　これでAMD64と戦える。
　この他にもあちこちに気になる・面白い内容が。


　このLoop Stream Detectorの制御を行うBranch Predictorにも手が入った(Photo10)。

　もっともその方向性を見ると、非常に興味深い(Photo11)。Banias〜Yonah〜Merom〜Penrynの

　世代はやはりMobile向けの設計だから、巨大サーバー向けのワークロードなどを考慮する

　必要はない(というか、それを考慮した結果としてメカニズムが増え、消費電力が増加する

　ことは容認できない)というポリシーで、この結果として同じアーキテクチャを使った

　Xeonなどが、結果としてOpteronに遅れを取る事になったとしても、

　これは仕方が無い事である。ただいつまでも「仕方が無い」では済ませられなかったようで、

　Opteron同様にマルチレベルのBranch Predictionを搭載することになった様だ。
　・・・ぬー。正直Mobileベースから派生の方がありがたいんだけどなぁ。
　やっぱり「鯖ベースとMobileを2系統同時に開発して、良い方をデスクトップに持っていく」のが
　理想なんだけど、無理なのかなぁ。


　なぜEPTが必要か? という話だが、従来のPage Tableの構造では、仮想化環境上のOSでPage Tableを

　参照しても、実際にはそれに該当するページをアクセスするためにはVMM上でもう一度Page Tableを

　参照する必要があった(Photo18)ため、非常にアクセスが遅くなるという問題があった。

　これを解決するのが、新しいEPTである(Photo19)。これにより、Guest OSからのアクセスが

　そのままダイレクトに物理アドレスに変換できるので、Page FaultによるVM Exitの頻度が大幅に減る、

　という仕組みである。これは要するに、AMDがBarcelonaから搭載したNested Pageの技法そのものである。
　これは確かにAMDが先行していたところ。現時点で私用で使う中では全く恩恵が無いので
　分かり難いところではありましたが。
　とりあえず、この辺りも(使う人は少なくても)順調に成長させてますよ、と。


　次はFast Unaligned Cache Accessである(Photo20)。現在のSSE系の命令の最大の欠点は、

　データのAlignmentが要求されることである。プレゼンテーションにもある通り、SSE系命令は

　原則として16Bytes Boundaryに沿った形でメモリをアクセスする。なので、データがこの境界を

　またぐ様な配置になっている場合、遅くなるのを覚悟でUnaligned命令を使うか、

　あらかじめデータの並べ替えを行ってからSSE命令を使うといった面倒さがあった。

　これに対し、NehalemではデータがUnaligned命令を高速化したことで、Unaligned命令を

　多用しても性能差が出ないようになった。これはSSE命令を使って、特に科学技術計算などを

　行わせる場合に大きく効果が出やすい。どちらかといえば、HPC用途を考慮した改良と言えよう。
　ほう。これはありがたい。


　さてそのL3 Cacheだが、今回は素直にInclusive Cacheの方式を取った。実は2007年の

　MicroProcessor ForumでIntelはMany Core時代のキャッシュ構成に関する研究を発表しており、

　このなかでMany Core世代ではNCID(Non-inclusive Cache, Inclusive Directory)が最適という

　見解を発表しており(Photo26)、Nehalem世代では最大8コアまでサポートされるから、

　あるいはこれを搭載してくるかと思ったが、素直にInclusive方式とした(Photo27)。
　この辺はどうにも比較しようが無いですが・・。


　ただその一方、果たしてDesktopやMobileにこれがどこまで効果があるのか? という疑問を

　抱かざるを得ないのも事実だ。TLB周りとかVT周り、SSE4.2のあたりは、まず間違いなく効果がない。

　L2キャッシュの高速化とかLoop Stream Detectorあたりは性能改善に寄与するだろうが、

　アプリケーションによっては同一周波数のPenrynと差が無いなんて結果が出ても

　不思議ではない構成に見える。
　以前どこかで、「IntelのCoreは高回転型エンジン、AMDのK8はトルク型エンジン」なんて表現を

　したことがある(*1)が、これを使うとNehalemはCoreの回転数をそのままに、下のトルクを増した

　という感じだ。恐らく、実際に使うと快適なのだろうが、ピーク性能はあまりCoreと変わりが

　無いかもしれない。勿論これはこれで進化なのだが、これまでIntelはピーク性能の高さを

　ウリにしてきただけに、どうアピールするのかちょっと興味深い感じだ。
　まとめ部。なるなる。ただSSEはDesktopには意味あるでショー。これからHD録画とかも
　来るんだし。
　まぁぶっちゃけNehalem世代ではTDPは下がらないんだから、Mobileではあと3年はPenryn及び
　32nm版でいい気がする。


　鯖向けをメインに強化した事で、恩恵はあまり無いかもしれない。つまり、
　DesktopやMobileとしての立場を考えた場合、"余計な消費電力が付いて来る"ようにも見える。
　先にも述べましたが、AMDが昔語っていた理想「2系統で同時開発、良い方(合う方)をDesktopに」が
　一番望ましいです。
　AMDにとっては所詮理想論でしたが。Intelですら出来てませんし。
　(ItaniumをやめてXeonと統合する、みたいな話がありましたがそうなれば現実か。)