Intel Fanboy Blog

RWTのSandy Bridgeの記事も怪しいので、公式documentもありますが、かのagner氏のsiteにある最適化マニュアル3の8章を訳してみました。
全文の中でSandy Bridgeについて記載のある一部分だけです。
色やlayoutをblog記事上で再現するのが面倒なため、PDF形式で公開します。掲載許可をくれたagner氏に感謝!

assembly言語が判読できないand英語が苦手な人が訳しているので、内容の精度は推して知るべしです。
assembly言語を真面目にやっている方や、英文に耐性のある方は素直にoriginalのdocumentを参照してください。

originalのdocumentは、下記のURLよりdownloadできます。
http://www.agner.org/

尚、今後、他のdocumentの翻訳をしていく計画はありません。

日本語訳

とりあえずRWTネタやろうかと思っているが、とても長いのでどうまとめたらよいのか暫くの間、考え中の予定…。

----------------------

Sandy Bridge was once known by the codename Gesher, 〜

Sandy Bridgeは、以前、ヘブライ語で橋を意味する単語であるGesherのcodenameで知られていた。大部分のIntelのcodenameは地名であるが、今回についてはGesherというcodenameは暗喩であると解釈できる。Sandy Bridgeは、Intel内部の3つの分断された世界の統合であり、Pentium Pro、Pentium 4 microarchitecture、GenX(第10世代) Graphics architectureの新実装、の3つの混合である。その混合の成果物が、32 nm processで製造される単一chipに、革新的なsystem infraと共に強固に統合されている。本記事はseriesモノの最初であり、Sandy Bridge microprocessorのmicroarchitectureに焦点をあてる。続編の記事では、graphics architectureと製品化を扱う予定である。

Intel’s first out-of-order microprocessor was the Pentium Pro (P6). 〜

Intelの最初のOOO microprocessorはPentium Pro(P6)であった。P6は、Oregonで着想、設計された。P6はまた、堅固にserver市場に目標を設定した最初のIntel CPUであり、最大4 socketのguelessなSMPをsupportしていた。当時、serverとworkstationは、独自設計のRISC architecture達に支配されていたが、Pentium Proは結果的にRISCの衰退と死の結末の鐘の音を鳴らすことになった。数種のRISC architectureは今日も生き残っている(特にPPCとSPARCが)、しかし、それらはx86の生態系にできるだけ遅れないための恒常的な競争の中にあって、実質の成長をもはや享受することもなく、少しだけ儲かるnicheにむしろ磔されている。

The P6 first arrived in 1995 on 0.5um and 0.35um BiCMOS processes〜

P6は1995年に0.5umと0.35umのBiCMOS processで初めて登場し、consumer志向のPentium II とPentium IIIにその後で改良された。一時期、P6製品系列は終焉かと思われる時期があった。P6の後継は、IA64(server向け)とPentium 4(client system向け)となる予定だった。Pentium 4は高度に革新的なmicroarchitectureで、前世代(P6)からの根本的な脱却であった。P6よりも更に積極的にout-of-orderで、過激な周波数へ調整されている。Pentium 4は、trace cache、simultaneous multi-threading, SSE2によるfirst classなSIMDのsupportといった多くの革新的なarchitcture上の選択を組み込んでいた。第2世代のPentium 4 microarchitectureのPrescottは最終的に、90nmで3.73GHzに到達している。

The insatiable desire for high frequencies unfortunately could not 〜

高周波数への飽くなき欲求は、残念ながら根底にある物理学の壁を乗り越えることができなかった。Intelの高周波数への一心な追求が高電力の動作を牽引することになり、mass marketの製品で130Wという経済性を考慮した一定の限界値が存在している。250Wや300Wで動作するchipへの電力供給や冷却は可能ではあるが、製品が非常に高価になり、高volumeでの生産はできない。残念ながらP4は高性能を獲得するための天文学的な周波数への到達を前提にしていた。AMDはこの弱点(とIntelのx86-64拡張の採用の遅れ)につけこんで、相当な市場shareを獲得した。

初めてAMDは、信頼の、推奨ですらあるserver用microprocessorの製造供給元になった。Intelの経営は最終的にPentoum 4の高周波数と高電力のapproachは袋小路だと悟った。彼らはP6に回帰したのだった!! 低電力なnotebookの応用向けにIsrael Haifaの設計teamが3世代(130nm Banias, 90nm Dothan, 65nm Yonah)にわたって改良してきたP6にである。

The 65nm Merom was the first P6 derivative since 2000〜

65nm Meromは、clientからserverまでの製品分布全体の橋渡しを志向した2000年以降では最初のP6派生品である。MeromはPentium 4とP6 uarchを統合する製品として宣伝されたが、しかし現実にはPentium 4からは他と比較して殆ど持ち込まれたものはない。にもかかわらず、Meromは成功し、IntelはAMDから徐々に市場shareをとり戻し始めた。45nmのNehalem uarchは、この正しい方向性の更なる一歩であり、Meromを基に、SMTと、新しくて大いにより効果的なsystem architectureを合体している。Nehalemの統合型memory controllerとon-dieのQuickPath Interconnectはserver市場でとりわけcriticalだった。だが、32nmのNehalemのshrink版であるWestmereは、Intelの最後のP6派生品になる予定だ。15年経って、P6はやっと新しいmicroarchitecture、Sandy Bridgeに置き換えられる。

The Sandy Bridge CPU cores can truly be described as a brand new microarchitecture t〜

Sandy BridgeのCPU coreは、P6と、P4の要素のいくつかを統合した新しいuarchだと全く言うことができる。Sandy BridgeはP6系列と最も強く似てはいるが、全く異なるmicroarchitectureである。coreのあらゆる特徴からみても、前世代のNehalemから殆どが大幅に改良されている。Uop cacheや物理register fileのような、これらの変更の中の多くは、Pentium 4 uarch由来の特徴や構想から集められた。Pentium 4は突き詰めると実装が弱点であり、沢山の良いideaを実現はしていた。P4のideaは業界のいたるところで再現されているし、Sandy Bridgeでもそうである。IntelのCPU設計で根底にある哲学は、core当たりの性能と実行効率の最大化である。このことは、core当たりの性能からthroughputの集合体としての強化へ若干後退しているAMDのBulldozerとは対照的になっている。本記事では、Sandy Bridgeのuarchを探求する!! 64-bit, quad-core, dual threaded, 4 issue, out-of-order microprocessor、新しい3-operandと4-operandのAVX命令set拡張がIntelの32nm processで実装されている。


System Architecture

As Moore’s Law has given more transistors with each generation, 〜

Mooreの法則が、各世代でより多くのtransistorをもたらにつれて、microprocessorの達成できる統合の水準は着実に上がっている。Intelはmemory controllerとcoherent interconnectをCPU側のsiliconの中へと移動した2008年の45nm Nehalemまでは、統合化というgameには寧ろ遅れるようになっていた。しかしながら、Mooreの法則で生きながらえる企業としてふさわしく、ここにきて統合化gameに凄まじい勢いで取り掛かってきている。32nmのclient版のWestmereは、そのmicroprocessorと、graphics、memory controller、などの機能を持つ対のdieとをpackageしている。この2つのchipはQPIを介して接続されている。Sandy Bridgeは、論理的な帰結で、前世代でみられる殆ど全てを、QPIを廃して単一の32nm dieへと統合している。Sandy BridgeはCPU core+L3 cacheと、GPUと、それ以外の全てを抱えるsystem agent (以前は’uncore’と呼ばれていた)という、3つの主要な領域に分けることができる。これらの主要なblockと、外部I/FはFigure 1.に示されている。Figure 1.に記載されている。このSandy Bridgeの周波数は、比較的high-endなmodelのbase clockを見積もっている。Dynamic Voltage and Frequency Scaling(DVFS) systemのおかげで、CPU coreとGPUは、ずっと高い周波数でtypicalに動作するだろう。Intelの製品releaseが近づくにつれて、実際のclockspeedがもっと確定していくはずだ。

Sandy Bridge uses a new 1155-pin socket that is not compatible with 〜

Sandy Bridgeは、前世代のArrandale/Clarkdale processorと互換性のないLGA1155-pin socketを使用する。一つの理由は、clockの生成法が変更されているからである。Motherboard上に個別部品のclock generatorを持つ代わりに、Intelの6-Series chipsetが、processorへDMIを介して単一のbase clockを供給する。このbase clockは、processor dieで逓倍され、全域に分配される。Clock generatorはGPUやmemory controllerと比べたら、小さな部品であるものの、統合化のもう1つの例でもある。

Figure 1 above shows the Sandy Bridge client, compared to Westmere and one node〜

上のFigure 1は、Sandy BridgeのClient版を、Westmereと、1 nodeの最初のBulldozerの実装(Interlagos)と、比較して示している。Interlagosは強固にserverを志向しているが、少なくとも1つのBulldozerの派生品がhigh-end desktop marketに登場する予定である。このversionのBulldozerが、高い周波数を趣向して、2 nodeの MCMを差し控えるかどうかは判然としていない。

Sandy Bridge’s memory controller should be a bit of an upgrade over 〜

Sandy Bridgeのmemory controllerは、前世代から少しupgrade版になるだろう。Arrandaleは、最高1.066GT/sに達する。そしてdesktopのCalarkdaleは1.33GT/sに到達することができた。Intelはspeedについて一切明らかにしていないが、Sandy Bridgeは少なくとも1.86GT/sで、よりextremeなsystemでは、もしかすれば2.13GT/sに達しうると考えるのも妥当に思える。Notebook用の低電力な領域では、LP-DDR3(1.5Vではなく1.35Vで動作するやつ)は、1.33GT/sで現在市販されているので、多分これは選択肢になるだろう。他の点では、主要なinterface群は、据え置きとなるだろう。

The Sandy Bridge clients will go into production later this year, with products for 1Q11.〜

Sandy Bridgeのclient版は今年の終盤に生産に入り、製品は1Q11の予定である。これは、AMDの競合製品で同じくon-dieのgraphicsを統合しているLlano processorが、1H11まで出荷が遅れていて、製品としてはさらに多分1四半期遅いため、大幅に進んでいるということだ。Llanoは、まだBarcelonaに基づいた派生uarchであり、CPU性能では大きく遅れをとると予想できる。もちろん、AMDのgraphicsの専門性であれば、LlanoのGPUはSandy Bridgeの第6世代Graphicsを凌駕するはずだ。Low-endでは、AMDはSandy Bridgeと同じ時期にBobcatの派生品を出荷するだろうが、これらは全く異なるsegmentの市場を担当するものである。

Sandy Bridge-EP, the mainstream server version will not arrive till 2H11 〜

Sandy Bridge-EPは、mainstream sever版であるが、2H11まで登場しない。恐らくQ3になる。Sandy Birdge-EPは、同じuarchにとどまるだろうが、異なるsystem agentになる。Sandy Bridge-EPは8 core、16MB L3 cache(いくつかの噂では20MBと言われる)、4つのDDR3 memory controller、2つのQuickPath 1.1 link、32 laneのPCIe 3.0を備えていると予想される。当然、その追加のI/Oが新しいsocketを必要とする。LGA2011は、電源とGNDのために恐らくより多くのピンを追加している。GPUやDisplay engineのような、Consumer志向の機能は、core、memory controller、I/Oの追加余地のために削除されるだろう。Sandy Bridge-EPは大雑把に言えば、Interlagosと同じ時期に出荷されるので、server購入者は、2つのuarchから選択することになるだろう。InterlagosはSandy Bridgeの最大2倍の多くのcoreを持っている。しかしながら、実際の製品の性能は、L3 cacheの設計や、周波数など多くの未知の要因に強く依存している。

Instruction Fetch
命令fetch

The job of the front-end of Sandy Bridge is to consistently deliver enough uops 〜
Sandy Bridgeのfront-endの仕事は、back-endを満杯の状態に保つために、命令streamから十分なuopを連続的に供給することである。最高性能のOut-of-order実行のCPUなら尚更、front-endの能力がなしでは乏しい結果を提供することになる。最近のどんなx86 CPUにとっても、これは全く挑戦的なことである。命令streamの供給は頻繁に分岐によって遮られる。そして、分岐の成立が、命令fetchを新しいaddressへと方向替えさせる時に、pipelineの中にbubbleを持ち込むかもしれない。uopへのx86命令byte列からのdecodeは、可変長、多様なprefix、非常に複雑なmicrocode化された命令というx 86命令の性質によって複雑になっている。Sandy Bridgeのarchitectはfront-endの全てのこれらの側面を改善するために相当な努力を費やした。

One of the most novel features of the Sandy Bridge microarchitecture〜
Sandy Bridgeの最も新手の機能の1つがuop cacheであり、これは可変長の命令の生のbyte列を格納するのではなく、固定長のdecoded uopを格納するものである。Uop cache内へのhitは、front-endの相当な部分をbypassし、back-endへのuopの供給を改善する。Uop cacheは、概念的にはPentium 4のtrace cacheと同質のものであるが、詳細は異なっており、次頁で探求するように、相当に改良・修正されている。


Figure 2 Sandy Bridge Instruction Fetch and Comparison
Figure 2. Sandy Bridgeの命令fetchと比較

One of the areas that Intel’s microarchitects concentrate on most keenl〜
Intelのmicroarchitect達が最も激しく専念した領域の1つが、分岐予測である。Intelが分岐予測をあの手この手で改善もせずに、世代を経ることは殆どないように思われる。その論理的根拠は、極めて単純である。性能を増すための多くの改善は、energyの使用も増加させるので、効率を維持するためには、microarchitect達は、新しい機能がenergyや電力を費やすよりも高い性能を獲得することを確実にしなければならない。分岐予測は、対照的に、性能の一般的な改善がenergyの使用を削減させる数少ない領域である。分岐の予測ミス毎に、pipeline全体がflushされ、最大で100個かそこらのin-flightな命令達がその仕事を失われ、そしてそれらの命令達に消費されたenergyの全てが無駄になる。従って、優れた分岐予測器によって高価な分岐予測ミスをなくすことは、とても好ましく、Intelの最優先の焦点になっている。

The branch prediction in Sandy Bridge was totally rebuilt for better performance 〜
Sandy Bridgeにおける分岐予測は、より優れたな性能と効率のために全体的に再構築されたが、同量の資源が使われている。Sandy Brdigeは、Nehalemで見られた4つの分岐予測器をえ置いている。分岐先buffer(BTB)、間接分岐先array、loop検出器、renamed return stack bufferである。Sandy Bridgeは単一のBTBで、NehalemのL1とL2 BTBの2倍の数の分岐先を保持し、より優れた分岐予測のカバー範囲を生み出している。この単一階層の設計は、分岐をより効率的に表現し、本質的に分岐あたりに必要なbit数を圧縮することで成し遂げられた。例として、予測器内の全ての成立する分岐が、現在の命令pointerからのdisplacementを持っているはずであるが、大きなdisplacementを持つ分岐は、別口のtableに保持することができるようになった。殆どの分岐(=short displacementしか持っていない)は、大きなdisplacementを持つ分岐と同じbit数を必要としないためである。IntelはNehalemでの分岐先の保持数を明らかにしなかったが、P4のBTBは4K分岐先を持っていた。従って、Sandy Bridgeは8K-16Kの分岐先を持つと考えるのが妥当に思われる。同時に重要なことに、最も最近に予測された(そして実行された)分岐を追跡するglobal分岐履歴は、より長い履歴patternを捕まえられるようにsizeを増した。繰り返すが、使用するbit数は増加してない!! 代わりにIntelは分岐の予測を立てるのに役にたたない特定の分岐をpattern履歴から省くようにしている。

Nehalem enhanced the recovery from branch mispredictions,〜
Nehalemは分岐予測ミスからの復帰を強化したが、これはSandy Bridgeの中にも持ち越されている。一度、分岐予測ミスが発覚すると、正しい実行pathがわかるやいなや直ぐに命令decodeを再startできると同時に、out-of-order machineが、誤って投機したpathからのuop達を捨てることができる。以前の命令decodeでは、pipelineが完全にflushされるまで復帰することができなかった。

The instruction fetch for Sandy Bridge is shown above in Figure 2〜
Sandy Bridgeの命令fetchは上のFigure 2.に示されている。分岐予測は分岐の成立時のstallが通常隠蔽されるように、命令fetchの少し前段でqueue化されている。この方法は、先行するMeromやNehalemでも使われていた。命令列が、L1I cacheから一度に16B fetchされるのに対し、予測は命令列32Bに対して行われる。

Once the next address is known, Sandy Bridge will probe both the uop cach〜

次のaddressが判明した時点で、Sandy Bridgeは、uop cacheとL1I cacheの両方を調べることになる。L1I cacheは、64B line の32KBで、仮想indexed、物理taggedを意味する連想度は、8 –wayに増加している。L1I TLBはsmall page用はthread間で分割されているとともに、large page用ではthread毎に専用化されている(訳注:つまりlarge page用は2つある)。Sandy Bridgeは、large page用に2つのentryを追加していて、4kB page用にtotalで128 entry(両thread分)、large page用にfully associativeな16 entry(thread毎)をもっている。

The instruction fetcher will retrieve 16B from the instruction cache into the pre-decode 〜

命令fetcherは、命令cacheからpre-decode bufferの中へ16Bを取り出してくる。このPre-decoderは、命令の境界を探してmarkづけを行い、全てのprefixをdecodeし、特定(例えば分岐命令)のpropertyをcheckする。このpre-decoderのthroughputは、16Bの命令fetchが消費されてから次のfetchを始めるまでで、6命令/cycleに制限される。Pre-decodeは、16Bの塊単位で行われるため、平均的なthroughputが、塊の末端部に苦しめられうる。例えば、第一のcycleで、15Bを4命令にpre-decodeすることができたとすると、残りの1B=1命令は第二のcycleとなるので、全体のthroughputとしては2.5命令/cycleになってしまう。大きな即値は、throughputについて同様の影響を及ぼしうる。pre-decode後、命令達は、decode用の命令queueの中へ配置される。Meromでは、この命令queueのsizeが18 entryであった。NehalemとSandy Bridgeでは、この命令queueはほぼ確実に増加されている。だが、正確な数字としてはわからない。

Instruction Decode and uop Cache
命令decodeとuop cache

Decoding fetched instructions in Sandy Bridge has not changed much,〜

下のFigure 3に示すとように、Sandy Bridgeでは、fetchされた命令のdecodingは、あまり変更されていない。この命令queueは、4つのpre-decode済み命令をx86 decoderへ送り出すことができる。Decoderはx86命令達の中から読み込みをし、下位hardwareでnativeに処理されるregularかつ固定長なuop達を放出する。4つのdecoderは、依然として非対称である。第一のdecoderは最大で4 つのuopを放出する複雑な命令を扱う。残りの3つの全てのdecoderは、より単純な命令を扱う。microcode化された命令(すなわち、4つより多いuopを生成する命令)については、microcodeが4uops/cycleの速さで命令がfinishするまでdecodeしていく。ただし、これらのdecode blockは、いつもの定番のdecoding blockである。Sandy BridgeとNehalemは共に、どんな命令mixでもdecoderが、ほぼ4uop/cycleでuopを放出することができる。


Most of the new 256-bit AVX instructions in Sandy Bridge are treated as simple〜
Sandy Bridgeでは、新しい256-bit AVX命令の殆どが、decoderでsimpleな命令として扱われる。実行unitとmemory pipelineにおける、いくつかのかなり賢い実装の成果のおかげである。前世代と同様、memory-register命令を1つのuopとしてdecodeできるように、実行unitとmemory pipelineは、uop micro-fusionに全て対応している。専用のstack pointer trackerもまた、Sandy Bridgeでも提供されていて、stack pointerをrenameし、serialな依存性を排除して、かつuopをいくらか削除する。命令はdecode後、そのuopがuop cacheへ送られ、またallocation, renaming, out-of-executionのためにback-endへと送られる。同一addressへの継続的な命令fetchは、通常の命令fetch、decodeのpathには頼るかわりにuop cache内へhitするだろう。

The most interesting part of Sandy Bridge’s front-end is the new uop cache, 〜

Sandy Bridgeのfrond-endで最も興味深い部分は、この新しいuop cacheであり、性能と電力消費の改善を約束している。Sandy Bridgeのuop cacheは、概念上decode済みの形式でcacheされる命令cacheの部分集合にあたり、trace cacheやbasic block cacheというわけではない。このuop cacheの目標の多くは、P4のtrace cacheと共通である。要はCPUのfront-endからの帯域を改善して、そのcritical pathからdecodingを排除することである。しかしながら、uop cacheは、trace cacheよりもずっと単純で、専用のtrace BTBや複雑なtrace構築論理を必要としない。Intelの典型的な手口だが、着想がまずMeromの命令loop bufferでみられ、その後でNehalemでuop loop bufferになり、最終的にSandy Bridgeで完全なuop cacheになるという、改良の傾向で一貫している。

In Sandy Bridge, the instruction stream is divided into a series of windows. 〜

Sandy Bridgeでは、命令streamは、windowの列へと分割される。各windowは命令達の32Bだが、もしかすればwindow内部の何らかの成立する分岐によって制限されている。命令cacheとuop cache間のmapppingは、完全な32B単位のwindowの粒度で行われる。ある1つのwindow全体がdecodeされてback-endへと送られた後、そのwindowはuop cacheの中へも挿入される。極めて重要なことに、この構築過程はfront-endの通常の作業に対して並列に行われるため、いかなるdelayも入り込ませることはない。

Lines in the uop cache are addressed by the IP of the first decoded x86 instruction stored〜

Uop cacheのcache lineは、line内に格納された先頭のdecode済みx86命令の命令pointerでaddress化されるので、uop cacheは仮想addressでaddressされている。このentryは2つのthreadがuop cacheを静的に分割できるようにtag付けされている。付加的な恩恵として、context switchまたはVM switchがflushを引き起こさせない(trace cacheでは引き起していた)。Uopはdecode済みの32B windowの粒度で働くので、擬似LRUの追い出しpolicyは、与えられた32 B windowに対応する全てのuop lineを一度に追い出す必要がある。自己書換えcodeもまた追い出しを発生するかもしれないが、uop cache全体を無効化はしない。

Sandy Bridge’s uop cache is organized into 32 sets and 8 ways, with 6 uops per line,〜

Sandy Bridgeのuop cacheは、32 setの8 way、6 uop/lineで、計1.5K uopの容量で構成される。Uopは厳密にはL1命令cacheの範疇に含まれる。各lineはまた、そのlineの中の有効なuopの数や、uop cache lineに対応しているx86命令の命令長などのmetadataを保持している。Uop cacheの中にmapされている各32B window達は、1 set=8 wayの内の3 wayに跨りうるから、すなわち最大18 uop!!で、大雑把に言って1.8B/uopである。32B windowが18 uop以上の場合、uop cacheに合わないので、旧来のfront-endを使わなければならない。Microcode化されている命令は、uop cacheの中へは保持されないで、代わりにmicrocode ROMへのpointerと、もしくは最初の数uopの形で表される。


According to Intel, the uop cache performs like a 6KB instruction cache and 〜

Intelによれば、uop cacheは、6KBの命令cacheのように振る舞い、大雑把に言って80%のhit率を持っている。ちなみに、P4の12Kuopのtrace cacheは、8KB-16KBの命令cacheに近い性能を持つと見られた。2つの設計間で記憶効率に4-8倍の開きがあるのは、Sandy Bridgeのuopがより強力でになったことと、Pentium 4のtrace cacheで厄介だった重複entryが排除されていることによりもたらされている。

Going back a bit to the instruction fetch, the predicted IP is used to probe the tags〜

命令fetchに少し戻ると、予測された命令pointerが、通常の命令cacheからと並列動作で、uop cacheからtagを検索するのに使われる。Uop cache tag達へのhitが、set、wayの識別子を生成し、その識別子がmatch queueの中へと入れられ、その後、uop cacheのdata arrayへのaccessに使われる。hitが発生すると、uop cacheは、32B window(言い換えると最大3 line)中のuopを全部、近くにあるqueueないしbufferの中へと読み出すだろう。uop cacheのdata arrayは、cycle毎に1つのlineだけ出力するので、1回のhitが完了するのには複数cycleを要するようである。Decoderと同じように、uop cacheはcycleあたり4つのuopをDecoder Queueへと送出することができる。しかしながら、uop cacheのhitは、32Bの完全なwindowの命令列に跨りうる。このことは16Bのfetchに制限されていた旧来のfront-endの帯域幅から倍化している。この追加の帯域が、平均で4 byteを超えるような命令長の場合にとりわけ役に立つ。例えば、AVX命令は2 byteか3 byteのprefixを使用している。加えて、各uop cache lineは、back-endのrenameとallocateするよりも多くのuopを保持することができる(4 vs. 6)ので、uop cache内で行われるqueuingが、分岐の成立によって持ち込まれるpipeline bubbleを隠蔽し、効果的に分岐の間を渡るつぎ合わせができる。

a hit, the uop cache calculates the next sequential IP using the 〜

Hitすると、uop cacheは、各uop cache lineに格納されている命令長のfieldを使用して次に続く命令のpointerを計算する。先に述べたとおり、分岐の成立は、旧来の分岐予測器で扱われる。Uop cacheがmissした場合には、fetchとdecodeは前に述べたように進められ、uop cacheは電力をsaveするため、clock gateされうる。

The Sandy Bridge architects decided that handling partial hits in the uop cache〜

Sandy Bridgeのarchitectは、uop cacheで部分hit(partial hit)を扱うのは、複雑すぎ、電力効率が悪いと判断した。部分hitの解決は、旧来のfront-endとuop cacheの両方の駆動と、更に2者の部分的な出力を同期させるための追加の論理を必要とする。Uop cache lineの配置、追出のpolicyは、各32 windowが完全にcacheされている(or完全にcacheに無い)ように設計されている。従って、hitが発生しても旧来のfront-endは巻き込まれない。

All the uops from the traditional front-end and the uop cache are ultimately delivered〜

旧来のfront-endとuop cacheからのuopは全て、28uop Decoder Queueの中へと最終的に配送される。Decoder Queueは、依然としてNehalemのように小さいloop用のcacheとして働き、実際、命令cacheとuop cacheをbypassすることができる。

One of the critical differences between the uop cache in Sandy Bridge〜

Sandy Bridgeのuop cacheとP4のtrace cacheの間の重大な違いの一つは、旧来のfront-endを拡大するように本質的に意図されているかどうかである。Pentium 4は、front-endを置き換えし、trace cacheにhitしない全てのworkloadのための非常に遅いfetchとdecodeの機構をアテにして、trace cacheを使うことを試みているのに対し、uop cacheは全てのworkloadで不利益をもたらさないように、Sandy Bridgeの1つの強化点として注意深く設計されている。

The uop cache is one of the most promising features in Sandy Bridge〜

Uop cacheは、電力の削減と性能の改善をするので、Sandy Bridgeの最も期待できる特長の一つである。Uop cacheは、複数のpipline stageに跨り、一様ではない命令setを扱うためにかなり高価なhardwareを要求する、x86の電力食いなdecodingを回避している。Sandy Brdigeの(分岐予測missのpenalty分の)pipelineは、uop cacheをmissした場合は、Nehalemのより2 stage分長くなるが、uop cacheへhitした場合は数cycle短くなる。Uop cacheは、より連続してuop をback-endに供給し、fetchとdecodeの処理に伴う様々なbubbbleをなくすることで、性能を増加させている。例として、16B fetchだったときは、命令長変更prefixと、decodeの制約事項が皆、旧来のfront-endに制限されていたのに対して、uop cacheは、それらの問題を無視して、高い性能を獲得することができる。概して、uop cacheは、より一層に電力効率的な方法の範囲内で多くの恩恵を提供しつつ、trace cacheの問題を回避したように見える。

[続く…]

先日、IDF2010でSandy BridgeがUop Cacheを備えていることが明らかになりました。

NetBurstではUop Cacheではなく、Trace Cacheと呼ばれる方式が採用されていました。

Trace Cacheは1995年にIntelから論文が出ていて、program上の高頻度の実行経路を動的に抽出しながらcacheするものです。分岐をまたいで命令をcache→fetchすることができ、一般にprogram中の分岐命令の出現頻度は高いので、使わずに捨てられる命令が少なくなり、高バンド幅のfetch設計でも無駄を減らすことができるというものです。また、x86の場合は、decode stageでx86命令をuopへと変換しているので、Trace Cacheの配置は、decode済みuop cacheとしての役割も兼ねることになります。
実際のところNetBurstの場合、Trace Cacheの出力帯域が3 uop/cycleしかなかったため、高バンド幅のuop fetchが目的というよりも、8 stageもあるfront-endをbypassするためのdecoded uop cacheとしての役割を狙ったものだったのではないでしょうか?

一方、Uop Cacheの方は2001年にIntelのIsrael teamから論文が出ています。命令の実行経路を格納するTrace Cacheに対して、Uop Cacheはdecode済みのuopをcacheする構造にで、この単純さからTrace CacheやXBC(拡張Block Cache, TCよりも高度)と比べて消費電力でmeritがあるようです。論文はfront-endがprocessor全体の28%の消費電力を消費していて、Uop Cacheを導入すればfront-endの消費電力を最大40%削減し得るというものです。

[paper] Micro-operation cache: a power aware frontend for variable instruction length ISA
http://www.cs.york.ac.uk/rts/docs/SIGDA-Compendium-1994-2004/papers/2001/islped01/pdffiles/p004.pdf

　といってもこの論文の内容がまんまSandy Bridgeの実装かといわれるとそうでもありません。10年近く前の論文であり、なかなか製品に実装されないのでUop Cacheはこの論文にあるような研究だけで終わるのかと思きや、再び最近になってIsraelがUop Cacheの実装例の特許を出しています。

[US Patent] EFFICIENT METHOD AND APPARATUS FOR EMPLOYING A MICRO-OP CACHE IN A PROCESSOR
http://www.freepatentsonline.com/y2009/0249036.html

個人的には、Sandy Bridgeで実装される可能性は低めなのではないかと思ってthroughしていましたが、IDFのslide資料を見る限り、この特許がほぼそのままの形で実装されていると考えられます。

NetBurstではUop Cacheというか実行Trace Cacheが12,000uopを格納できるようになっています。それに対して、次世代のSandy Bridgeの実装では1,500uopと、1/8の数のuopしか格納できません。NetBurstは最初期の実装がWillametteですので、180nmのprocess技術での投入を前提にしているuarchであるのに対し、Sandy Bridgeは32nmのprocessが前提のuarchです。両者を比較するとprocess技術に五世代もの開きがあります。Intelはこの後に及んで相当ケチなんだなと思いたくなります。しかし、Sandy Bridgeのuop cacheがNetBurstの実行Trace Cacheと比較して小さくなってしまうのには、それなりの根拠が2つ見つかります。

1つめは、NetBurstでは実行Trace CacheはL1I cacheとしての役割も兼ねていることです。NetBurstの場合、Trace CacheをmissしたらL2から命令をfetchしなければならないので、trace cacheのhit率は高くする必要があります。しかも、命令fetch〜decodeの遅延が高clock狙いの設計のため、ただでさえ長いのに1 uop/cycleの帯域しかもっていません。NetBurstは、Trace Cacheにhitする前提の割り切ったfront-end設計のuarchだったわけです。
対してSandy BridgeはIDFでもL0Iとして説明されているように、1.5k uop cacheと32kB L1I cacheの出力はMUXされていて、miss-hit時でも従来通りL1Iが働く構造になっており、帯域的にもCore 2以降のfront-endの強力さをSandy Bridgeでは踏襲していて、uop cacheに期待されているhit率は低くても性能的にはあまり影響がないと考えられるためです。

2つめは、(というかこれがこの記事の本題なのだが、)Pentium M以降のIntel x86は、uop長が非常に長いことです。NetBurstとPentium Mのuop長を推測するのに有力なsoruceとして下のIntelの論文があります。

[paper] Clustering-Based Microcode Compression
http://iccd.et.tudelft.nl/Proceedings/2006/paper_203.pdf

論文ではNetBurstのuop長が75-bitであると言及されていて、その他Pentium Mなどもmicrocode ROMのcolumn sizeから命令長が推測できてしまいます。
その他のsourceも含めて現在判明しているIntel系x86 processorのuop長は下の表のようになります。

processor	uop長
Pentium Pro	118-bit
NetBurst	75-bit
Penium M	234-bit
Dothan?	236-bit
Yonah?	240-bit
Bonnell	60-bit

Pentium Proのuopである118-bitからPentium Mの234-bitではいきなり2倍近くになっていることについて、uop fusionが影響しているのではないかと推測しているsiteがありましたが、今はもう消えました。論文にある”Mobile”という分類の2つの謎のprocessorは、236-bit, 240-bitのuopを持っているようですが、論文が書かれた当時の背景からいくと、それぞれDothanとYonahを指していると考えています。

このようなuop長の変化から察するに、現代のx86は命令をuopに変換する方式をうまく利用して、uarchの制御上都合が良いようにuopのformatを世代ごとに最適化して定義しているのかもしれません (制御情報を低い密度で持つことによって内部で扱いやすくなる代わりに、命令長が長くなるのかも) 。
そして、Core 2(Merom)、Nehalem、Sandy Bridgeでは、EM64T/SSE4/AVXや物理register数の増加など、様々な拡張を続けているので、更に長いuop長を持っているのではないかと推測されるわけです (32bit長のRISCなんて古典です) 。

仮にSandy Bridgeのuop長を256-bit(32B)であると仮定して計算すると、1.5k uop cacheの容量は、
256-bit * 1500uops = 47kB
となりL0Iと説明されていながら、その容量はL1Iの32kBよりも大きくなります。また、uop cacheの出力帯域としても、4 uop/cycleを想定すると、
256-bit * 4 uops/cycle = 1024-bit/cycle
もの広帯域になってしまうので、帯域と容量のtrade-offを考えると、32nm世代とはいっても無闇に容量は増やせなかったのではないでしょうか? (元々Pentium Mのようにuop長が長いuarchは、uopをcacheするのには容量や帯域的に向いていないので、Sandy Bridgeでは特許の実施はないと思ったのです)

NetBurstの場合、論文によればuop長は75-bitと比較的短いので12kuop, 3 uop/cycleなら
12,000uop * 75-bit = 110kB
75-bit * 3uop/cycle = 225-bit/cycle
となり、Sandy Bridgeの仮想定と比べて大分楽そうです。

ちなみに、お馴染みのHans de Vries氏の初期のDie分析ネタで、Trace Cacheの容量を推測したものがありました。

[Chip-Architect] Looking at Intel's Prescott die
http://www.chip-architect.com/news/2003_03_06_Looking_at_Intels_Prescott.html

Northwood Trace Cache: 256 kByte / 2.4 = ~ 106 kByte +/- ?
Prescott Trace Cache: 256 kByte / 1.6 = ~ 160 kByte +/- ?

NorthwoodのTrace Cacheの容量が106kBというHans de Vries氏の推測と、先の論文を元にした計算とはほぼ一致しています(残念ながらHans de Vries氏は、この推測結果を捨ててその後の記事で誤った解釈に進んでしまいますが…)。Sandy Bridgeのuop長については不明ですが、Hans de Vries氏がDie分析してくれれば、Uop Cacheの面積からおおよそのuop長は推測できそうです。

　ちなみにIsrael teamはTrace Cache周辺の論文も多く出しています。その路線の一つの完成形がParrotであり、PC Watchで後藤氏が推測しているように、Intelがcore拡張の路線にもっと回帰すれば将来的に、FTC/MTCやParrotの実装があるのかもしれません。

OOO以降のmicroprocessorはstage間に様々なBufferやQueueを持っているので、最近のIntelの拡張はそれらを大容量化して付加機能をもたせている感じです。Sandy Bridgeで実装されたDecoded Uop Cacheは、Nehalemでの28 uopのLSD Bufferを拡張したという解釈もされています(28uopsって時点で初期P6のRSよりも大容量なのですが)。　　　renamedなcacheの研究もあるようなので、この調子で行くと将来的にはrename済みのuopまでもがcacheされ、bypassされたりするかもしれません。(現代はpipeline registerじゃなくてpipeline buffer/cacheが当たり前の時代なのだろうか?)

[US Patent] Method and apparatus for a double width load using a single width load port
http://www.freepatentsonline.com/y2009/0164763.html

内容からしてあからさまにSNBなIntelの特許出願を発見。
殆どこのまま実施されてそうです。

Sandy Bridgeでは256bのdataset幅を持つAVX命令を新たにsupportしています。
そのためかload portが2つに増えることになっていますが、各load portは128bの実装です。
128bの実装で256bのdatasetに対応するため、各load unit内で256b loadを2つに分割するという特許です。

load unitで最初に128bのloadか256bのloadかを判定し、256bであれば128b x2に分解して、128bのmemory accessを2回分連続するcycleでdata cache unitへdispatchするという仕組みを採ってます。
既に巷で話題になっていますが、SNBでの256bのcache accessはこの実装のためにやや遅くなると見られます。下位128bの内部stackの方がdata cacheにより近い位置に配置されているそうです。

ここで味噌なのは、256b loadを上位128bと下位128bの2つのuopにdecodeして発行するのではなく、単一のuopを発行してload unitの中で分割するという方式を採っていることです。当然1つの256b loadを2つのload portに振り分けることもありません。

また、128bのdatasetであるか256bのdatasetであるかの情報bitをload uopが含んでおり、128bの場合も256bの場合も同じload uopが発行されます。
この理由は、

any increase in the number of micro-operations supported by a microprocessor results in a corresponding increase in area and complexity of the microprocessor

と書いてあるとおり、uopの数を増やすとprocessorの面積と複雑さが増すためです。

内部的には256b loadの場合、上位128b→下位128bの順に実行されます。上位128bに1 cycleのdelayが挿入されているため、
実行unitが結果を受け取るときには上位下位が結合され、同じcycleになるようです。
実効addressは上位128b分はAGUが生成しますが、下位128b分はMOBが生成します。
valid/faultの判定は後に実行される下位128bの結果だけを拾えばよいなどの理由により、RS等OOOのためのqueue/buffer類のentry消費も1 uop分で済むようです。

おまけですが、最後の方に128b→256bのSIMD効果で、多くの手動最適化アプリで+50%の速度up、自動vector化compilerを使用したアプリでは+20%の速度upと書いてあります。

IDF Beijing, April 13-14, 2010
http://www.intel.com/IDF/
4/13-14にIDF北京があるようですが、今更ながら直前の悪あがきということで、Sandy Bridgeネタを簡単に。


Sandy Bridgeの性能は新TBの実力とcache周辺のlatencyに大きく依存しているため、予想が難しい。
memory/cache accessがprocessorの性能向上の足かせになっている昨今、個人的には、L1Dのlatencyが3 cyclesか悪くてNehalemと同等の4 cyclesであれば、load portの増えたSNBはIPC面でそれなりに期待できると思いますが、現在のところ5 cycles以上の説が有力ですね。

0.Socket roadmap

1. Turbo Boost
http://pc.watch.impress.co.jp/img/pcw/docs/318/033/html/kaigai7.jpg.html
Sandy BridgeのTBは、上のlinkのslide資料によれば、
- Responsiveness
- 37% frequency gain(4 core, up to 1 minute)
- Fully deterministic behavior
となっているので、温度が低ければ、TDPを超えてのOC動作をすることになるのだが、
Fully deterministic behavior == 完全に決定論的な振る舞い
と書かれているので、温度sensorの温度を最初見て、そのあとは電圧・clock・時間を決めうちで判断して最大1分間はOCが可能ということのようである。

Nehalemの場合は、常に温度sensorをmonitorしながらTBをしているので、新しい電圧・clockを反映するのに温度sensorでの計測〜出力、PCU(マイコン)への入力〜演算の遅延があるが、Sandy Bridgeではこれが大幅になくなるので応答性が改善する可能性がある。実際、Responsivenessとかいてある。

それに付随して、Nehalemのように冷却系に依存してTBの動作が変わるという状況は減ると見られる。しかし、一方で冷却系がSNBの想定外の能力だったりとすると温度があがりすぎたり、逆にTBの動作を限界まで引き出せない状況も発生しうるかもしれない。


2. Zeroing Idioms
http://img130.imageshack.us/i/sandybridge.jpg/
上のlink先にあるSandy Bridgeの公式block図では、Allocate/Rename/Retireのところに、Zeroing Idioms(ゼロ化慣用句)というのが
赤枠==SNBでの新機能
として書かれている。これはなにかというと、憶測であるが、XOR EAX,EAX or SUB EBX,EBXのようなzero化のidiomをpipelineの早期に認識して、re-order buffer上にある物理registerのentryをclearすることで実行の代わりにして、消してしまうのではないかと。ちょうどAllocate/Rename/RetireはP6〜Core 2系のcoreではre-order bufferに相当するstageである。
これを行えば、zeroing idiomについてはALUやschedulerを使用しないのでpipeline上のresourceの節約や、電力の節約になる。まあ、これだけだと効果は微々たるものなのでこれ以上の何かであることを期待したい。


3.その他
以下は、Israelの論文や特許などから判断して、もしかするとあるかもしれないレベルの話なので殆ど真に受けない方が身のため。
- cacheのhitやmissを事前に予測器で予測し、しかるべきpipelineの動作ができる
- load unitが2つになるため、L1D cacheの同じbankへaccessが2つのload portで被った場合にはcache accessのpipelineにstallが発生する。これをcrossbarで検出するようにして回避しようとするとcache pipeのstageが増えてL1Dのlatencyが増えるので、Sandy Bridgeではload命令がaccessするcache bankをschedulerの前に予測器で予想して、極力別bankへのload operationになるようにscheduleできる可能性がある(いや普通にcrossbarでSNBのL1D latency増えるかもしれないが…)。

/*今更ながらNehalemではL1Dのlatencyが3→4 cyclesと同process同容量でありながらPenrynよりも増えましたが、RWT説ではSMT対応のためって話だったけど、16B un-alignmentなcache accessのpenalty対策をした副作用が原因かもなあ。

個人的にはIntel IsraelはCore 2でのmemory disambiguationのようにcache/memory access周りで期待している。Sandy BridgeでもAVX対応で単にL1Dのload帯域を32B/cycleにするのではなくて、128bのload portを2つ用意してきており、schedule面での工夫で既存のprogramの高速化のやる気があるのかもと思わせてくれる。まあ、あっても今回のIDFで明らかにはならない気がするけど、投機的なload/storeのschedulingに隠しだまを期待しています。
*/

[TG daily]Overclocking Nehalem “almost as good as having a second graphics card” - Intel
http://www.tgdaily.com/content/view/38988/135/

At the Intel Developer Forum today in San Francisco, Intel’s Francois Piednoel and Matt Dunford outlined the various issues in benchmarking people will face when testing the new chips.

Turbo mode will dynamically alter the speeds of the four cores once the processor gets out of a thermal envelope. Dunford and Piednoel told reporters that the BIOS menus will have a menu to select thermal dissipation (TDP) numbers. If you have a really good heatsink, you could crank this number to 190 watts. Conversely, an average heatsink would warrant a rating of 140 watts or below. Once the processor detects that it’s going out of this envelope, it will start clocking itself up/down. The processor will also try to move poorly threaded applications to few cores.

先日のIDFでIntelのFrancois Piednoel氏とMatt Dunford氏からTG dailyのreporterが聞いた話だと、BloomfieldのsystemはBIOS上のmenuからTDP値を任意に設定できて、本当に良いheat sinkを使用していれば190Wにも設定可能だろうという。平均的なheat sinkでは140W以下とのこと。

/*
こりゃガセ情報かもしれないけど、Turbo Mode(多分別記事であとで説明)はTDPの範囲内で各coreの周波数を動的に制御するので、190Wに設定すればmulti-threadでも殆どの時間、+2〜+3段階のoverclock状態を維持できる、というようなことも考えられるわけでそりゃすごい。Nehalem以降は冷却系の設計や部品選びで実性能に差がでてしまうのが当たり前ということに。

ちなみに、Nehalemの定格の周波数はTurbo ModeでOCしている時と区別して、Intelでは今のところ"TDP frequency"(TDP周波数)と読んでいるようです(TDPの範囲内でOCしかしないはずなのによくわからん呼称だ)。
*/

[もっと書くかもしれない]

[Intel] Getting to the Core -- Intel's new flagship client brand
http://blogs.intel.com/technology/2008/08/getting_to_the_core_intels_new.php

Believe it or not, this new naming scheme should make it easier for PC buyers to decide which technology is right for them. The “i7” identifier is the first of several new identifiers to come as different Nehalem-based products launch over the next year
〜中略
i7 is only the first identifier in the Intel Core Processor family, noting the highest performing desktop processors in the family.
〜中略

Nehalem Microarchitectureの最初の製品であるBloomfieldは結局Core i7というbrandnameになったわけだけど、Intelの公式Blogによれば、"i7"というidentifier部分は来年launchされる別のNehalem-basedな製品では異なるそうで、high-end desktopを区別するためのもの。

PC購入者がわかりやすいようための新しい命名schemeの一環ということでLynnfield/Havendaleでは異なる識別子になるようです。"i7"という記号と数字の由来には別段意味はないとのことのようです。

// というわけで、CPUIDがどうとかuArch世代がどうとか関係ないからしい。

[この記事は書きかけです]

とりあえず、多分、AnandTechの解説が今のところ一番詳しいと思われる。でも、あまり新発見はなかった。解説も無難だし。

[AnandTech] Intel's Atom Architecture: The Journey Begins
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3276

とりあえず、page 6〜9まで見て、わかったこと

(1) 1 for 1はNehalemからではなくAtomからだった。
(2) Atomは初めsingle issueとして開発が開始されたが、直ぐに2 issueへとwide化された。
(3) Atomのdecoderには、slow pathとfast pathがある。slow pathは3 cycleにつき1命令しか生成できない。fast pathは1 cycleにつき2命令生成できる。命令は一度Slow pathで実行されるとtagをつけられ、次回からfast pathで扱うことができるようになるらしい。また、fast pathでは投機的なdecodeも一部supportしている。
(4) Safe Instruction Recognition (SIR, 安全な命令認識)のalgorithmによって依存関係を判別し、大きなlatencyを実行中に、続く短いlatencyの命令を先行して実行できる。これで無駄なstallを抑制している。

/*
AtomのSMTって+20%〜30%の性能向上で、実際+20% TDPがあがってるから、ほんと1 for 1だね。ただし、multi-thread限定。

Atomはin-orderだが、未来永劫このsegmentのIntel processorがin-orderだとは思わない。でも、あと5年でOOOはないだろう。…っていうAnandTech(の記者)の意見には同意です。

Atomでよく言われるLoad-op-Storeのpipelineっていうのは、命令を実行するのに、memからdataをLoadして、実行unitでOperationして、WB stageで結果をmemにstoreするという直列的な構成のことを言っているわけ。これは、RISC以前の昔、大型computerやVector型computerの時代ではよく見られたもので、Atomのblock図ではその通りL1Dへのaccessと実行unitが直列的になっている。RISC以降の近代的なpipelineでは、interlockを避けるためにLoad/Storeが実行unitに並列に配置されていて命令も専用化されるようになった。MIPSが、Microprocessor without Interlock Pipeline Stagesの略だったことを思いだそう。RISCの発想が主流になって久しいので、Atomのblock図にはものすごい違和感を感じてしまう。もちろん、P5などでも同じようになっているはずだがAtomの場合pipeline stage数が多いからこういう絵になるのだろう。
*/

//以下、page 6〜9のしょぼ要約の垂れ流し

Intel's Atom: Changing Intel from the Inside
---------------------------------------------------------
長年、Intelでは電力vs性能の経験則はこれだった: 1%のperformance増加のために2%の電力増加ならば設計者はそのfeatureをmicroprocessorへ追加することができる。残念なことに、これはPentium 4やその派生製品で使われたNetBurst architectureをもたらした。

Intel Atomは、この経験則の要求を1%の性能増加に対して、1%の電力増加に再定義して設計された最初のIntel processorである。これは革新的な変更であるし、他のIntel architecture(Nehalemなどが思いつく)でも観られるものだが、Atomが最初である。

Atomはsingle-issue, in-order microprocessorとしてstartしたが、Austin teamは直ぐにdual-issueのcoreへと設計をwide化した。しかしながら、in-orderの決定は変えられなかった。

今日のx86 processorは命令をprogram orderから外れて操作できる。(中略)。OOOE(Out of Order Execution)の能力があるProcessorは、cache上にdataが利用可能でないときに、data待ちでidle状態になる代わりに、他のreadyな命令達をmemoryからdataがfetchされている間に実行することができる。

これらout of order processorの問題は、この命令のreorderingが、追加のdie spaceと電力消費の増加を要することである。Performanceは向上するが、Intelのここでの目標はfastestではなく、fast enoughである。従ってAtomはin-order CPUのままであり、original Pentium processor以来ではIntelの初のin-order x86 coreとなっている。In-order化の決定は、複雑性と電力食いの回路の必要性を解消した。Out-of-order実行からは良好なperformanceが得られるが、それに対応したschedulingの複雑さの増加が単純に45nm Atomには大きすぎたのである。Intel CPUでout-of-order実行がPentium Proまでは相応しくなかったように、transistor sizeが十分に小さくなり、OOOの実装がAtomでも相応しくなるときがくるかもしれないことを覚えておこう。しかしながら、私は次の5年間のうちにそのOOO化の変更が見られるとは思わない。


2-Issue and In-Order: Intel's Version of the Cell's PPE
---------------------------------------------------------
Austin設計teamは、single-issueのin-order coreとして、設計をstartしたが、直ぐにsuperscalarの2-issueな設計へと拡張した。つまり、最大2命令をpipeline中で同時に発送できる。比較すると、殆どのdesktop x86 microprocessorは3または4-issueの設計になっている。

2-issue を供給するためにIntelはAtomに2つのdecoderを設けている。Decoderは命令をL1I cacheからfetchし、1/0の並びを解析して命令がCPUに何をさせるか明らかにする。これらDecoderは命令をdecodeする能力において等価である一方で、命令によって選ばれるかもないslowとfastの2つのpathを持っている。

x86 ISAは以前から、可変長命令をsupportすることに関して多くの批判をされてきた。もし10秒に2個のオレンジが渡すと言われれば、あなたの仕事は10秒に1〜3個のオレンジを渡されるよりも遙かに簡単になるだろう。前者は固定長命令の例であり、後者は可変長命令の例である。残念ながらx86は後者の分類に該当する。

Atomのslow decoding pathは、投機的なdecodeは何もできない。命令は手動で順序され、各bitは(時間をかけて)調べられるが、命令は正確にdecodeされることが保証される。また、命令は次回からはfast pathに送ることができるようにtagをつけられる。

Fast pathは、明らかに投機的なdecodeを複数採用しており、それはslow pathを通った後にsetされるtag bitに助けられている。Slow pathは、3 clockにつき1命令を生成する。一方、fast pathは、1 clockで2命令を生成できる。

IntelがBanias (Pentium M)で学んだように、不正確な投機による電力penaltyは、batteryで駆動するdeviceでは歓迎できない。Atom Processorでは、投機的な性能上の仕掛けが、低電力動作を維持するために犠牲にされる、多くのtradeoffがみられるだろう。

Instructions Gone Wild: Safe Instruction Recognition
---------------------------------------------------------
従来のin-order architectureで最も恐ろしいのは、cache上にないdataを要求する高latencyの命令である。

In-order microprocessorでは命令をin orderに実行しなければならないので、CPUがmain memoryからdataを取ってくる(100 cycles以上)まで実行unitがidleのままになる。問題なのは、このcyclesの間、何も働いていないにもかかわらず電力が浪費されることである。これは超低電力なuPが欲しいということに反している。

OOO processorでは、単純にこの問題を依存命令のschedulingによって逃れている。Schedulerは単純に実行に対してreadyかつmain memory上のdataを他の命令が待っていても仕事ができる命令を選択する。既に完全OOOE coreはAtomには電力を食い過ぎることを確認した。しかし、純粋なin-order設計をあてにすることもまた非効率になる可能性をもっている。Intel Austin teamは、賢い中間解を見つけた。

それは、Safe Instruction Recognition (SIR) algorithmと呼ばれているもので、以下のように働く。Atomが長いlatencyのFP演算を実行している時、続く短いlatencyの整数演算は、伝統的にはFP演算がcompleteするまでstallすることになる。SIR algorithmでは2つの命令を調べ、data依存があるかどうか判別する。もし依存がなければ、Atomはより新しい短いlatencyの演算を、より長いFP演算に先行して開始することができる。

SIRは、極限られた場合についてではあるが、OOOの利点の一部をAtomの完全なin order設計へちりばめる。私はもし将来のAtomで、このようなOOO風のtrickを採用する状況が拡大しても驚かないだろう。

Return of the CISC: Macro-op Execution
---------------------------------------------------------
Pentium Proは、1990年代初頭のRISC vs. CISC論争をついに終わらせた最初のIntel CPUである。ProgrammerにとってみればPentium Proは、それまでのIntel processorのようにまだx86 CISC machineである。しかし、内部的にはx86命令を受け取ったあと、単純で、速く、効率的なRISC coreで実行できるように、より小さなuopへとdecodeしている。

(中略…　その後Pentium Mのuop fusionで効率の観点からCISC風のtrendが復活　…のような話 )

Atomは、Pentium Mからさらに一歩推し進めて、殆どのx86命令を分解すらしない。AtomはOOO coreではないため、大量のuopをin-flightに持つことは適切ではない。さらに殆どの命令を単一の操作に保つことによってIntelは、Atomの”width”を効率的に増加させている。

Load-op-storeやload-opの命令formatは、Atomのdecoderでは単一のuopとして扱われる。つまり、dataをloadし、演算し、結果をstoreするある命令は、今、3つのuopに分解される代わりに単一のuopとして扱われる。Pipelineを下るuopは1つだけになる。Atomは、2-issueのarchitectureに過ぎないかもしれないが、ある状況では、はるかにwiderなmachineとして振る舞うのである。

Intelは、RISCのようなより小さい操作にx86命令を分解する機能を完成させて、これらのatomicな操作に対処するcoreを非常に高い性能に構成することに過去の10年間の多くを費やした。しかし、Intelは現在、これらx86命令を多くの場合分解せず、正反対のことをしているのである。

[この記事は書きかけです]

246 名前：名称未設定 ：2006/12/10(日) 20:43:47 ID://BurDBo0
Die Stackingを使うとメインメモリの帯域改善やキャッシュの大容量化ができるのは
いいが、それがメニィコアに向いているという説明は疑問だよな。
で、勘のいい人はすぐに気がつく。

Die Stackingによってメインメモリがプロセッサ内蔵になるとSoC化の波にますます拍車がかかると…。

メモリの帯域や遅延の改善は、別にメニィコアじゃなくても恩恵がある。

(1) クロックを上げる
(2) 命令レベル並列性のUP
(3) マルチスレッディングやマルチコアによるTLP性能のUP
(4) 特殊用途HW、SIMD、ベクトルプロセッサ化
　(↑表スレのパクリ)
という高速化手段があったとして、最初は(1)でいきたかったけどこけて、今(3)の方向に向いているわけだが、
Intelがメニィコア、マルチスレッドを強烈に推すのは、スレッドレベルでパフォーマンスアップを
今までのように継続して高価なプロセッサを今までどおりのやり方で売りつづけたいから。
もし、メニィコアがこけるとハイエンドマイクロプロセッサに従来のような価値がなくなり、
薄利商売になりかねないから、Intelとしては死活問題。

しかし、メニィコアは実際には、実現や普及が難しく、プランBとして考えられるのがより現実的な統合化路線なわけ。
コア数は1-4で、(4)の路線の高速化を行いながら、ストレージやI/Oを統合化するというのがまあ、妥当なゾーンだろう。
実際にUMPC向けに統合化チップを開発しているのはよく知られている事実。

コンピュータの歴史では、より小さく、より安価なものへと市場の主役が移りかわってきており、
メインフレーム/ミニコンの時代にはECL部品でCPUを構成するdiscreteなやつがハイエンドだったのが、
やがて熱と遅延の問題にぶち当たり、サーバ/PC時代の現在では、CPUといえば、CMOSで製造される
ハイエンドマイクロプロセッサのことで、メインフレームやスパコンまでも含めてこれに置き換わっている。

最近になって、このハイエンドマイクロプロセッサさえもかつてのメインフレーム用プロセッサと同様に、
熱と周辺チップとの遅延の問題に悩まされている。

行数が足りなくなったので終了。

247 名前：名称未設定 ：2006/12/10(日) 20:46:45 ID://BurDBo0
とどのつまり今はハイエンドマイクロプロセッサからハイエンドSoCの時代への転換期なのかもという結論の
妄想ネタでした。

248 名前：名称未設定 ：2006/12/10(日) 20:57:11 ID://BurDBo0
メインメモリが内蔵化・高速化すると、シングルコアの高速化においても、
ハードウエアへの投資効率が大幅に改善され、シングルスレッド性能の延命につながる。
ハイエンドSoC時代ではもっと小型なPCが大量に売られる。
PCの時代がいつまでもつづくとは限らないが、
しかし、IntelやMSは既存のPCアーキテクチャやソフト資産を広めたい。
PCの今後のライバルは携帯電話や携帯用ゲーム機である。
等の話が続く予定だったが、長くなりそうなので省略。

時代が追いついてきた。もういっちょだ。

ケータイネット世代のきもち
http://journal.mycom.co.jp/series/mobilecom/001/index.html
/*
世代交代。
PC技術を追いかけてきたものとして、素直に新しい携帯機器世代を歓迎するよ、私は。

computerの歴史では、最大の市場を形成するものに最大の投資が与えられ、最新の技術が結集する。今はserverとPC向けのprocessorに最高のchip技術が結集しているが、今、馬鹿にされているかもしれない携帯機器、組み込み向けchipに次第に最新技術が集まっていく(市場が大きくなると新製品の投入間隔も短くなり、上位の筈のcomputerの性能をやがて逆転するcaseがでてくる。supercomputerも1 chipではPCと同等以下のものばかり。で、PCは今後coreは増えるかもしれないが、single-threadでは…みたいな考え)。

現在のsupercomputerや大型computerがPCやserverのお下がり技術で成り立っているのと同様、据え置き型のPCも、やがて携帯機器技術のお下がりの寄せ集めになりかねない。個人的な観測ではあと7,8年くらいが一般認識の境目かなあと。
これがcomputer業界の最後のinnovation。

その後は産業革命以降、多くの産業がそうであったように、(今は米国が握っている)computerの中核技術も徐々により西へ(米国→アジア圏)中心の産業へとシフトして、成長期を過ぎ、先端産業としての時代が終わるんだろうと…。Asia圏の台頭はあと10〜15年くらいで観てる。

ここでhigh-end SoCという自前の用語をあえて使った意味は、high-end microprocessorが最新のchip技術を結集してひたすらperformanceを追求しているのと同じで、die-stackingなどが実現してくると、電力や発熱や遅延の観点から性能追求の結果がSoCになりかねないから。low-end向けの技術と見られているSoCの逆襲なわけだけど、言葉で区別して考えてる。最近のserver chipが電力制御に力を入れているのは、それなしでは性能を高められないからだね。このことは携帯機器の優位性を高めることにもmatchしているわけで。

IntelのLPIAの開発が報道されたとき、多くのmediaでIntelが携帯電話市場に参入したみたいな書かれ方をされていた。でも厳密には違うだろう。PCの次担うかもしれない重要なcomputer市場に早めに手をつけたかっただけだろう。うかうかしてると他のarchに持ってかれてしまうからね。Appleも同じような理由で次の覇権のための先行投資でPA Semiとかだったりして。

今はcontents serviceの時代で、hardwareやsoftwareのみたいな媒体中心の見方自体が古いんだろうけこれは案の一つということで。

上の記事を引用した理由。
携帯型のcomputer、1人多数台のcomputerの時代では、K/B, Mouseと同じような機能をどうやって小さく実現されているのだろうと悩むわけだが、人間の適応能力が思った以上に高いみたいで。
*/

Intel Value to HPC Environment
http://ludit.kuleuven.be/onderzoek/images/e/eb/16042008_Intel_HPC.pdf

Web巡回していたら、今年の4/16付の新しいroadmapの資料を偶然みつけました。



SandyBridgeでもSMT続投なんだ。Nehalemでネタがないからやっただけで、SandyBridgeでは消える可能性も考えていたんだけどそうではないようです。ここから素直に推測するとSandyBridge世代のhigh-end Desktop(Bloomfieldの次々世代)も6cores, 12 threadsになる可能性が高そうです。しかし、このRoadmapではimpressの報道と異なり、Westmere-EPが6 coresではなく、4 coresということになっている。あと、8 core版のBecktonがNehalem-EXからNehalem-XSにいつのまにか改名されたのか(?)。もちろんXeon MPに相当するSandyBridge-EXの計画もある。

Westmere世代のMainstream chipのcodenameはClarkdaleで、2〜4 coreです。45nm Nehalem世代では2 core IGPのHavendaleとLynnfieldに分かれていたんだけど共通のcodenameに統一するのかな(?)。