Nehalem

下文中介紹的Nehalem的技術指標主要是以Nehalem-EP（Gainestown）為範例來介紹的，該核心將會用於Xeon DP，就是用於伺服器的雙路CPU。Nehalem是4核心、8線程、64bit、4超標量發射、亂序執行的CPU，有16級流水線、48bit虛擬定址和40bit物理定址。

比起從Pentium 4的NetBurst架構到Core 微架構的較大變化來說，從Core 微架到Nehalem架構的基本核心部分的變化則要小一些，因為Nehalem還是4指令寬度的解碼/重命名/撤銷。

Nehalem的核心部分比Core 微架構新增加的功能主要有以下幾方面：

New SSE4.2Instructions （新增加SSE4.2指令）

Improved Lock Support （改進的鎖定支持）

Additional Caching Hierarchy （新的緩存層次體系）

Deeper Buffers （更深的緩衝）

Improved Loop Streaming （改進的循環流）

Simultaneous Multi-Threading （同步多線程）

Faster Virtualization （更快的虛擬化）

Better Branch Prediction （更好的分支預測）

Nehalem使用的QPI匯流排是基於數據包傳輸（packet-based）、高帶寬、低延遲的點到點互連技術（point to point interconnect），速度達到6.4GT/s（每秒可以傳輸6.4G次數據）。每一條連接（link）是20bit位寬的介面，使用高速的差分信號（differential signaling）和專用的時鐘通道（dedicated clock lane），這些時鐘通道具有失效備援（failover）。QPI數據包是80bit的長度，發送需要用4個周期。儘管數據包是80bit，但只有64bit是用於數據，其它的數據位則是用於流量控制、CRC和其它一些目的。這樣，每條連接就一次傳輸16bit（2Byte）的數據，其餘的位寬則是用於CRC。由於QPI匯流排可以雙向傳輸，那麼一條QPI匯流排連接理論最大值就可以達到25.6GB/s（2×2B×6.4GT/s）的數據傳送。單向則是12.8GB/s。

對於不同市場的Nehalem，可以具有不同的QPI匯流排條數。比如桌面市場的CPU，具有1條或者半條QPI匯流排（半條可能是用10bit位寬或單向）；DP伺服器（雙CPU插座）的CPU，每個具有2條QPI匯流排；而MP伺服器（4個或8個CPU插座）的，則每個具有4條或更多的QPI匯流排。

Nehalem的IMC（integrated memory controller，整合內存控制器），可以支持3通道的DDR3內存，運行在1.33GT/s（DDR3-1333），這樣總共的峰值帶寬就可以達到32GB/s（3×64bit×1.33GT/s÷8）。不過還並不支持FB-DIMM，要Nehalem EX（Beckton）才有可能會支持FB-DIMM（Fully Buffered-DIMM，全緩衝內存模組）。每通道的內存都能夠獨立操作，控制器需要亂序執行來降低（掩蓋）延遲。由於有了Core 2近4倍的內存帶寬，Nehalem的每個核心支持最大10個未解決的數據緩存命中失敗（outstanding data cache miss）和總共16個命中失敗，而Core 2在運行中則只支持最大8個數據緩存的和總共14個的命中失敗。

IMC能夠很顯著的降低內存延遲（尤其是對於採用FB-DIMM方案的系統）。下面的Nehalem與Harpertown，我不清楚是什麼頻率情況下的對比（來自於IDF上的表格，可能Nehalem是3.2GHz）。Nehalem的本地內存延遲大約是Harpertown的60%。Harpertown系統使用的是1.6GT/s的前端匯流排，所有內存都在一個位置，大約是略低於100ns（納秒）的延遲，這樣Nehalem的內存延遲就是約60ns。對於2個CPU插座的Nehalem來說，使用的是NUMA結構（Non Uniform Memory Access Achitecture，非均勻內存存取架構），遠方內存的延遲則要高一些，因為這時對內存的請求和回應需要通過QPI匯流排，其延遲大約是Harpertown的95%。所以，即使是最糟糕的情況，延遲還是得到了降低。一個有意思的問題是，當使用4個CPU插座的Nehalem時，延遲是否將會被增大？因為這種系統很有可能會使用FB-DIMM，而這意味著將遭受延遲損失，不過遠方內存的延遲還是將只會比本地內存慢個約30ns。

對於其它使用IMC和核心互連的多CPU系統（例如EV7、K8、K10），內存延遲也是非均勻的（NUMA）。為了優化性能，操作系統就必須知道延遲差異，並調度那些在同一個CPU上共享數據的進程。Windows Vista是Microsoft的第一個為NUMA進行優化的操作系統，而Linux等則已經很早就可以支持NUMA了。

Nehalem的遠方/本地延遲比是約1.5倍。衡量K8的NUMA係數（也就是遠方延遲除以本地延遲）在2 CPU系統時也差不多是1.5。而在4 CPU系統時，INTEL將具有優勢，因為所有的內存要麼都是本地（當QPI匯流排上沒有hop時），或者所有內存都是遠方（QPI匯流排上有一個hop時）。因為使用對角線連接，每個CPU都有QPI匯流排連接，那麼遠方內存最多就一跳（1個hop）。而現在的4插座的K8或K10系統，有的內存在HT匯流排上多達有2個hop。總之，具有更大的NUMA係數，就更需要軟體考慮其所使用的內存的位置。作為參考，其中最早一個具備IMC和核心互連的EV7，在其64 CPU的系統中，NUMA係數為1.86-5.21（1-8個hop的情況）。

同步多線程（Simultaneous Multi-Threading，SMT）技術又重新回歸到了Nehalem架構，這最早出現在130nm的P4上。對於打開了SMT的CPU來說，將會遭受到更多的命中失敗，並需要使用更多的帶寬。所以Nehalem比P4是更適合使用SMT的。另外，在移動和桌面領域的Nehalem有可能將不會支持SMT，它們也不需要3通道內存。

為什麼Core 2沒有使用SMT？很顯然，它是可以做到的。SMT是在節省電力的基礎上增加了性能，而且軟體支持的基礎建設也早就有了。有2個可能的原因：一是Core 2可能沒有足夠的內存帶寬和CPU內部帶寬來利用SMT獲得優勢。通常，SMT能夠提升內存級并行（memory level parallelism，MLP），但是對於內存帶寬已經成為瓶頸的系統則是個麻煩。而更有可能的原因則是SMT的設計、生效等是很麻煩的，而當初設計SMT是由INTEL的Hillsboro小組主持，而並非是Haifa小組（Core 2是由這個小組負責的）。這樣Core 2不使用SMT就避免了冒險。

Nehalem的同步多線程（Simultaneous Multi-Threading，SMT）是2-way的，每核心可以同時執行2個線程。對於執行引擎來說，在多線程任務的情況下，就可以掩蓋單個線程的延遲。SMT功能的好處是只需要消耗很小的核心面積代價，就可以在多任務的情況下提供顯著的性能提升，比起完全再添加一個物理核心來說要划算得多。這個和以前P4的HT技術是一樣的，但比較起來，Nehalem的優勢是有更大的緩存和更大的內存帶寬，這樣就更能夠有效的發揮。按照INTEL的說法，Nehalem的SMT可以在增加很少能耗的情況下，讓性能提升20-30%。

對於SMT的各線程間所採用的資源共享策略有許多種：

1、複製型—— 線程都可以複製使用

寄存器狀態

重命名RSB（重命名返回堆棧緩存）

大頁表ITLB

2、靜態分配型—— 一般由線程平分

各種主要的緩衝：讀取、存儲、重排序

小頁表ITLB

3、競爭共享—— 由線程動態佔有

保留站（RS）

緩存（Cache）

數據TLB（DTLB），L2 TLB

4、不受影響

執行單元

Nehalem同時也降低了同步原語（起始同步），比如LOCK prefix、XCHG和CMPXCHG等指令的延遲。同步原語在多線程編程中是必需的，而多線程的擴展性被同步所限制，通過降低延遲，可以提高現在多線程軟體的性能。INTEL宣稱，Nehalem的LOCK CMPXCHG指令（其作用是使整個流水線串列化）的延遲是P4的約20%，Core 2的約60%。儘管降低了延遲，但行為仍然和以前的CPU還是一樣的，鎖定指令（Lock）並不是管道化的，即使後面的操作可以被提前到鎖定指令之前來執行。

（指令拾取和解碼）

1、指令拾取（包括分支預測）

在Nehalem的指令拾取單元（instruction fetch unit）中包含有相關指令指針（relative instruction point，RIP），每個線程狀態（thread context）各有一個。在指令拾取單元中還包含有分支預測器，用來預測下一條將被拾取的指令的RIP。對於分支預測器的很多細節，INTEL並沒有公布，但它們是適合於工作在SMT模式的。並且Nehalem也將繼續使用上一代的那些特殊的分支預測器，比如循環檢測器（loop detector），間接預測器（indirect predictor）等。

當分支預測器選定一條分支時，分支目標緩衝（branch target buffer，BTB）就負責預測目標地址。Nehalem使用了2級BTB結構。作為參考，K10使用了一個有2K 項（entry）的BTB用於直接分支，和一個有512項的間接分支目標陣列（indirect branch target array）。Nehalem的兩級BTB設計，非常適用於有大量指令代碼的任務，例如資料庫、ERP和其它的商業應用，通過提高分支預測準確度而提升性能和能效。INTEL沒有發布詳細的內部結構。下面作出一些有依據的猜測。

有兩種可能。一是兩個BTB使用同樣的預測演演算法，而一個存取更小一點的歷史文件，包含最近時間內所使用的分支RIP和目標RIP。在這種情況下，它們的關係就象L1緩存和L2緩存一樣（因為分支目標也具有相當好的地址相關性）。舉個例子，比如L1 BTB有256-512項，而更大的L2 BTB則有2K-8K項。如果分支RIP在L1 BTB中沒有找到，然後就到L2 BTB中去找，以作出目標預測。

另一種可能（RWT認為這種可能性比較小）則是兩級BTB使用不同的預測演演算法和不同的歷史文件。比如L1 BTB使用簡單而快速的演演算法和相對較小的歷史文件，而L2 BTB則使用更慢但更準確的演演算法，而且被配置成是具有優先權的預測器。如果L2 BTB不同意L1 BTB的預測，則它可以撤消（override）L1 BTB的預測，去除掉流水線中錯誤拾取的指令，而從新預測的RIP處重新拾取指令。這種結構可能性不大，因為它的能效比較低下。對於這種預測器架構，通常的情況是L1和L2 BTB都獨立的得出正確的分支目標——這就意味著在大多數的時間裡，L2 BTB都是在浪費能源。而L1 BTB錯誤，L2 BTB是正確的情況，只佔非常小的比例。

不過在更早一點的ANANDTECH的文章中有提到認為是第二種方式：通常會遇到這樣的情況，L1 BTB作出預測是基於分支的類型，但實際上它並沒有歷史數據，這樣準確度就很低。而L2 BTB有更多的歷史數據，就可以提高準確度，而且L2 BTB可以在執行過程中就糾正（L1 BTB所給出的）錯誤預測，而避免性能損失（這就正是override的情況）。

現在不清楚哪一種觀點更正確一些。

Nehalem另一個提升分支目標預測的機制是對返回堆棧緩衝（return stack buffer，RSB）進行了重命名。當發生程序調用時，RSB就記錄下地址，這樣當結束調用返回時，就從該地址繼續執行下去。但是當有很多程序遞歸調用時，RSB將會溢出，並且如果分支預測錯誤，那麼也將會產生錯誤的返回地址。Nehalem通過重命名RSB，就避免了溢出。並且錯誤的分支預測也不會毀壞RSB，只要調用與返回地址是正確配對的，那麼就可以從Nehalem的RSB中得到正確的數據。對於每一個線程都有一個專用的RSB，避免任何交叉弄髒數據。

拾取單元取得了每一個線程預測的下一個地址（通常情況下也就是正確的下一個地址），就到ITLB（指令旁路轉換緩衝）和L1 I（一級指令緩存）去標註。ILTB由每個線程靜態分配（平分），有128項緩存4KB的小頁表，是4路聯合方式的緩存；另外，每個線程還有7項用於緩存大頁表文件（2MB/4MB），是全聯合方式。L1 I是32KB，4路聯合方式，由線程競爭共享。進入指令緩存后，每周期16Byte（128bit）的指令發送到預解碼和拾取緩衝（pre-decode and fetch buffer）。然後，每周期6條指令從預解碼和拾取緩衝發送到有18個項目數的指令隊列（instruction queue）。在Core 2中，指令隊列被用做循環緩存（Loop Stream Detector，LSD，循環流檢測器），這樣碰上小循環（指令數≤18）的時候，指令拾取單元就可以被關閉。而Nehalem的指令隊列則只是作為指令被解碼前的緩衝，因為它的循環緩存在流水線級數中，被放到了解碼階段的後面。

2、解碼

當X86指令進入指令隊列后，它們就等著被解碼成微操作指令（uop），這是一種類似於RISC的指令。Core 2和Nehalem都有4個解碼器，一個複雜解碼器和3個簡單解碼器。簡單解碼器能夠處理可以解碼成一個uop的X86指令，現在絕大多數SSE指令都是這種。複雜解碼器能夠處理解碼成1-4個uop的X86指令，而比這還要複雜的指令，則由微代碼序列器（microcode sequencer）來處理。

Nehalem改進了宏操作融合（macro-op fusion）。Core 2可以在32bit模式下，把TEST/CMP（比較指令）和其後的Jcc（條件分支指令）給解碼融合成一個微操作（uop）：CMP+Jcc。這樣就增加了解碼帶寬，並減少了微操作數量。而Nehalem的宏操作融合則包括了更多的條件分支指令：JL/JNGE, JGE/JNL, JLE/JNG, JG/JNLE。TEST/CMP和這些條件分支指令都將被解碼成一個微操作：CMP+ Jcc。而且，Nehalem的宏操作融合可以是32bit和64bit模式。這是很重要的，因為現在大多數伺服器都運行的是64bit操作系統，即使是桌面電腦也開始更多的歡迎64bit操作系統了。

一旦X86指令解碼成微操作，就進入有28個項目數的微操作緩衝（uop buffer），Nehalem將其作為前面介紹到的LSD（Loop Stream Detector，循環流檢測器）。如果一個循環不大於28個微操作，則Nehalem就可以將其緩存在LSD里，併發送到亂序執行引擎去執行，而關閉指令拾取單元和解碼器。這樣通過關閉解碼器和使用更大的循環，就能夠比Core 2的LSD節省更多的能耗。Nehalem的28項的微操作緩衝，能夠保存相當於21-23條X86指令（根據在一些遊戲中的測試情況得出的估計）。X86指令轉換為微操作的比率取決於工作量的不同，不過總的來說，Nehalem具有比Core 2更大一些的LSD緩衝。

比較有趣的是，Nehalem的LSD緩衝看起來更象是指令追蹤緩存（trace cache）。指令追蹤緩存的目標是以動態程序的順序來存儲微操作，而不是象指令緩存里那樣以靜態編譯順序存儲X86指令，因此可以從關鍵路徑（critical path，指需要時間最長的路徑）中去掉解碼器和分支預測器，而使得被堵塞的地方可以立刻取得指令。P4的指令追蹤緩存的問題在於它太脆弱了，當其命中失敗時，就必須一個接一個地（重新）解碼指令。通常指令緩存的命中率是在90%以上，而指令追蹤緩存卻遠低於這個標準，很少時候超過80%，大多數時候是在50-60%。也就是說，在40-50%的時間裡，P4都表現得象是一個單發射微處理器，而不能夠完全利用上它的執行資源。而Nehalem的LSD緩衝取得了和指令追蹤緩存幾乎同樣的目標，而且當它無法工作的時候（即當循環太大時），也沒有什麼要命的性能損失。

在LSD緩衝之後，解碼步驟的最後一步是專用堆棧引擎（dedicated stack engine），除去所有被堆棧更改過的微操作。堆棧更改過的微操作都是被一個專用加法器給執行過了的，並寫到前端的一個推測寄存器（speculative delta register）。推測寄存器偶爾會和重命名結構的寄存器（renamed architectural register）同步，而重命名結構寄存器中則保存有堆棧中的非推測值（non-speculative value）。當堆棧處理過的微操作都被清除之後，剩下的微操作就進入亂序執行引擎去被重命名、發送、分配和執行。

（Out-of-Order Engine and Execution Units）

Nehalem的亂序引擎顯著的擴大了，除了性能原因，還有就是為了提供SMT，因為SMT需要資源共享。

和Core 2一樣，Nehalem的寄存器重命名表（register alias table，RAT）指明每一個結構寄存器（architectural register）要麼進入重排序緩衝（Re-Order Buffer，ROB），要麼是進入撤銷寄存器文件（Retirement Register File，RRF，或翻譯為引退寄存器文件），並且保持有絕大多數最近的推測值狀態（speculative state）。而RRF則保持有絕大多數最近的非推測狀態（non-speculative state）。RAT可以每周期重命名4個微操作，給每一個微操作在ROB中一個目的地寄存器（destination register）。被重命名的指令就讀取它們的源操作數並被發送到通用架構的保留站（unified Reservation Station，RS，可以被各種指令類型使用）。

Nehalem的ROB（重排序緩衝）從96項增加到128項，RS（保留站）從32項增加到36項，它們都由兩個線程所共享，但是使用不同的策略。ROB是靜態分配給2個線程，使得2個線程在指令流里都可以預測得一樣遠。而RS則是競爭共享，基於各線程的需求。這是因為許多時候一個線程可能會中止，從內存等待操作數，而使用到很少的RS項。這樣就不如讓另一個更活躍的線程儘可能多地使用RS項。在RS中的指令當其所有操作數都準備好時，就被分配到執行單元去。

Nehalem的執行單元與Core 2相比，基本沒有大的改變，而且並不受SMT的影響，除了使用率更高之外。

幾乎Nehalem的所有方面都是略為改進並增強，但存儲子系統（memory subsystem，或翻譯為內存子系統）卻是非常激烈的大修理。

Nehalem可以同時運行的讀取和存儲量增加了50%，讀取緩衝由32項增加到了48項，而存儲緩衝由20項增加到了32項（增量還略多於50%）。增加的原因自然是為了讓兩個線程共享，這裡採用的是靜態分配，可能是由於關鍵路徑的限制。

從讀取緩衝和存儲緩衝，存儲操作就繼續訪問到緩存架構。Nehalem的緩存架構是完全革新了的。象P4一樣，所有的緩存和數據TLB（Translation Lookaside Buffer，旁路轉換緩衝，或叫頁表緩衝）都是由2個線程動態共享（根據已經觀察到的行為）。Nehalem的L1 D（一級數據緩存）保留了和Core 2一樣的大小和聯合度（associativity），但是延遲卻從3個周期增加到了4個周期，以適應時間限制（timing constraint）。另外前面已經說到，每一個核心可以支持更多的未解決的命中失敗（outstanding miss），最多到16個，可以利用更多的存儲帶寬。

而Nehalem剩下的緩存結構則和Core 2截然不同。Core 2的最後一級緩存是L2，由2個核心共享，這樣可以減少一致性錯誤（coherency traffic），數量達到了24路聯合的6MB（Penryn），延遲是14-15個周期（Conroe是14，Penryn是15）。而Nehalem有3級緩存，前兩級相對較小，是每個核心私有的，而L3則非常大，由所有核心共享。

Nehalem的每個核心有一個私有的通用型L2，是8路聯合的256KB，訪問速度相當快。其使用延遲時間還沒有完全披露，不過INTEL的工程師表明是小於12個周期的。Nehalem的L2相對於其L1D來說，既不是包含式（inclusive）也不是獨佔式（exclusive），就象Core 2一樣，Nehalem可以在兩個核心的私有緩存（L1D和L2）之間傳遞數據，儘管不能夠達到全速。

Nehalem的16路聯合、8MB的L3對於前兩級來說，是完全包含式的，並且由4個核心共享。儘管INTEL並沒有完全說明Nehalem的物理設計，但似乎L3緩存是單獨使用電力，並運行在單獨的頻率上。這是從節省電力和可靠性這兩個方面推斷出來的，因為大的緩存更容易在低電壓下產生軟錯誤（soft error）。這樣，L3使用延遲就取決於相對頻率、核心的相差（phase alignment）、L3自身，還有訪問L3的仲裁器的延遲。在最好的情況下，即操作相差和頻率差距是整數倍的情況下，Nehalem的L3使用延遲是在30-40周期（根據INTEL工程師的說法）。

使用包含式緩存的好處是可以處理幾乎所有的一致性流量問題（coherency traffic），而不需要打攪到每個獨立核心的私有緩存。如果在L3中發生命中失敗（cache miss），那麼要訪問的數據就肯定也不在任何一個L2和L1中，不需要偵聽其它內核（而獨佔式緩存，則還要回頭去檢查其它內核）。

另一方面，Nehalem的L3對於緩存命中成功（cache hit），也扮演著偵聽過濾器（snoop filter）的角色。獨佔式緩存命中成功時，不需要檢查其它內核，而包含式緩存則一般需要檢查其它內核。但是在Nehalem的L3中的每一個緩存行（cache line）里，有4 bit是用來做核心確認（core valid）的，表明是哪一個核心在它的私有緩存里具有這個行的數據備份。如果一個核心確認位被設置成0，則那個核心就不具有該行的數據備份。Nehalem使用的是MESIF緩存一致性協議（MESIF cache coherency protocol），如果兩個以上核心的確認位都有效（設置成1），那麼該緩存行就被確定是乾淨的（即未被修改的，任何一個內核的緩存行都不能夠進入更改模式）。當L3緩存命中，而4個核心確認位都是0時，就不需要對其它內核做偵聽；而只有1個位是有效時，則只需要偵聽那一個核心。這兩種技術的聯合使用，使得L3可以儘可能的讓每個核心避免數據一致性錯誤，這樣就給出更多的實際帶寬。

事實上，並非只有包含式緩存這一種解決之道。對於非包含式緩存來說，通過和最後一級緩存一起複制所有私有緩存的標誌文件（tag file），並同時檢查所有的最後一級緩存的訪問標誌和私有緩存的訪問標誌，也可以達到同樣的性能好處，並避免數據一致性錯誤。而包含式緩存則是設計得必須複製數據，這就能夠表明各級別之間大小的一定關係。Nehalem的每個核心有64KB L1D和256KB L2（有可能L1D的數據包含在L2中，也可能L1D的數據並沒有包含在L2中。因為L2並非包含式），這就意味著在8MB的L3中，有1-1.25MB的數據是前兩級緩存中也有的數據。這就是包含式緩存額外的開銷。

Nehalem的緩存架構設計得也更容易支持非對齊（unaligned）的訪問，有更快的非對齊緩存存取。INTEL前幾代晶元一直是用兩種類型指令來做16Byte（128bit）的SSE讀取和存儲，一種是其數據必須正好和緩存行（16B）對齊，比如MOVAPS/D、MOVDQA指令——（數據）必須剛好是16Byte，和緩存行對齊。另一種則可以是未對齊的，比如MOVUPS/D、MOVDQU指令，數據對齊與否是沒有要求的。

在Nehalem之前，處理對齊的指令更有優勢，而處理非對齊的指令則更慢、具有更低的數據吞吐量（即使其數據是在對齊的情況下），需要多個微操作。編譯器也總是避免后一種指令，盡量避免非對齊的讀取，象MOVSD+MOVHPD這樣的2條連續指令就會更快一些。

而Nehalem則對非對齊指令進行了優化：在存取對齊數據的時候，非對齊指令和對齊指令具有一樣的延遲和吞吐量。同時也提高了非對齊指令對於非對齊數據的訪問速度。這樣，不管是什麼類型的SSE操作，都具有相同的延遲。另外Nehalem對在存取數據時跨越了64-Byte緩存行邊界的情況也進行了優化，比起Core 2具有更低的延遲和更高的吞吐量。這樣，編譯器就不會再懼怕使用非對齊的指令了。

除了改變緩存架構，Nehalem還改變了TLB等級架構。TLB是用來緩存虛擬地址和物理地址映射關係的。Core 2有著非常有趣的TLB安排，L1 DTLB（INTEL有時也叫做micro-TLB）非常的小，並且只用來讀取。它有16項小頁表（4KB page）和16項大頁表（2M/4M pages），每一個都是4路聯合。L2 DTLB更大一些，可以讀取和存儲（當在L1 DTLB中讀取失敗時，就到L2 DTLB中來讀取，並且L2 DTLB負責所有的存儲），它有256項小頁表和32項大頁表，也都是4路聯合。

Nehalem則建立起了真正意義上的兩級TLB體系，可以動態分配給SMT的活躍線程狀態（thread context）。Nehalem的L1 DTLB可以做所有的存儲訪問（可以讀取和存儲），它有64項小頁表和32項大頁表，也都是4路聯合。而新的L2 TLB是通用型的（可以用於指令和數據），它只有512項小頁表，也是4路聯合。

Nehalem和Core 2的TLB的一個明顯的差異是它們覆蓋緩存的深度不同。Core 2（Penryn）有6MB L2，通過使用小頁表（絕大多數的應用都不使用大頁表），TLB可以轉換2176KB的內存（地址），這樣就覆蓋了1/3的L2。而Nehalem的一個核心有576項小頁表，整個CPU總共則是2304項，這樣TLB就可以轉換9216KB的內存，這已經超過8MB L3的容量了。

Nehalem的TLB項還通過使用虛擬處理器ID（Virtual Processor ID，VPID）而有所變化。每一個TLB項都緩存一個內存頁的虛擬地址到物理地址的轉換。而這個轉換是特定於一個給定的進程或虛擬機（virtual machine，VM）。當處理器在虛擬客戶端和主機之間切換時，INTEL過去的CPU都要往TLB里填寫，以確保進程只能夠訪問到它們被允許訪問的內存。而VPID則跟蹤是哪一個VM的TLB項，這樣在該VM退出后又重新進入時，TLB就不用填寫也能夠確保安全。如果一個進程試圖訪問不是它自己的地址轉換，則就會直接在TLB中命中失敗，而不會是到頁表中去做非法訪問。VPID通過降低虛擬機地址轉換的開銷（overhead）而有助於提升虛擬化性能。INTEL估計，Nehalem的一個來回的VM地址轉換的延遲約是Conroe的40%，約比Penryn低1/3（即約是Penryn的66%）。

Nehalem另一個虛擬化方面的改變是擴展頁表（Extended Page Tables，EPT），用來消除許多VM地址轉換，即減少轉換次數（而VPID的作用是降低VM地址轉換的延遲）。通常的頁表是用來匹配客戶機的虛擬地址和客戶機的物理地址，然而在一個虛擬化系統中，也有從客戶機的物理地址到主機的物理地址的轉換。INTEL早期的CPU（和AMD在Barcelona之前的CPU）將需要系統管理程序（hypervisor）來處理頁面錯誤，而Nehalem則通過EPT，來消除了許多不必要的虛擬機退出。

以適應不同的市場需求。

模塊化組件有：

1、核心數量

2、SMT功能

3、L3緩存容量

4、QPI連接數量

5、IMC數量

6、內存類型

7、內存通道數量

8、整合顯卡

9、能耗和時鐘頻率

未來預定會發布的幾種Nehalem有：

Gainestown，用於Xeon DP

Bloomfield，定位於高端桌面市場

這兩種將於08年4季度上市。RWT認為可能Bloomfield將沒有SMT。

2009年發布：

Havendale，桌面雙核

Auburndale，移動雙核

Clarksfield，移動四核

Beckton，用於Xeon MP

Lynnfield，桌面主流四核

Nehalem的電路級技術，可能得等到秋季IDF才會公布。AMD的4核，其電路設計就發生了非常大的改變，從原來的1個變成具有5個時鐘分佈網路（clock distribution network），有3個不同的電壓層（voltage plane），並在不同時鐘域（clock domain）之間使用動態FIFO。估計INTEL也將採用類似的手段來控制功耗和提升性能。現在比較有意思的問題是INTEL將採用何種動態時鐘技術（dynamic clocking technique）來提升單個線程的性能。現在的Penryn已經可以動態提升一個核心的頻率和電壓，當另一個核心是空閑的時候。而這項技術顯然對Nehalem是更有用的。

Nehalem微架構分為兩個主要部分：計算內核與非計算內核

一. 計算內核的設計來源於之前的微架構，並對其進行了優化和加強，主要為以下幾個方面：

(1) 支持超線程----第三代超線程技術，四核心時多達八個線程

(2) 支持虛擬化設備輸入/輸出 (VT-d)----在之前以虛擬化CPU為主的基礎上增加設備輸入/輸出的虛擬化，能有效提高虛擬機的性能和效率。

(3) 內核加速模式(Turbo Mode)----內核運行動態加速。可以根據需要開啟、關閉以及加速單個內核的運行。例如，在一個四核的Nehalem 微架構處理器中，如果一個任務只需要兩個內核，可以關閉另外兩個內核的運行，同時把工作的兩個內核的運行主頻提高。如果任務只需要一個內核，可以關閉其它三個內核，同時把工作的一個內核提高到更高的主頻運行。這樣動態的調整可以提高系統和CPU整體的能效比率。

(4) 新增的SSE 4.2指令集等等。

二. 非計算內核的設計改動令人矚目，主要的有：

(1) Cache的設計----採用三級全內含式Cache設計，L1的設計和Core 微架構一樣；L2採用超低延遲的設計，每個內核256KB；L3採用共享式設計，被片上所有內核共享。

(2) 集成了內存控制器(IMC)----從晶元組上移到CPU片上，支持多通道DDR3內存，內存讀取的延遲大幅度減少，內存帶寬大幅提升，最多可達三倍。

(3) QPI----"快速通道互聯"，取代前端匯流排(FSB)的一種點到點連接技術，20位寬的QPI連接其帶寬可達驚人的每秒25.6GB，遠非FSB可比。QPI最初能夠發放異彩的是支持多個處理器的伺服器平台，QPI可以用於多處理器之間的互聯。

目前，基於Nehalem微架構的Bloomfield處理器(Bloomfield也是產品代碼)已經正式命名為"酷睿 i7"。酷睿是品牌，"i7"是系列編號。酷睿這一名稱現在和未來都將是英特爾公司PC處理器產品的旗艦品牌。

首款基於Nehalem微架構的處理器將是用於台式機的處理器酷睿 i7，支持的晶元組為x58。這款處理器有4個內核，計劃在今年第四季度上市。用於伺服器和筆記本電腦的Nehalem微架構處理器也會在將來陸續上市。

熟悉英特爾公司的人大概都知道每個英特爾的產品或者具有代表性的技術在開發的時候都有一個產品代碼或者項目代碼。這些代碼不會用於正式的產品上市，只會用於開發階段的溝通。

英特爾產品上市時使用的正式品牌和產品名的確定要遠遠晚於產品的立項和開發階段，產品的品牌和產品名涉及的方方面面太多，如法律方面的：商標註冊，使用範圍；人文方面的：用戶接受度等等。

因此，為了溝通方面，就先使用代碼溝通，英特爾公司把代碼的選擇權交給項目組或者項目的負責人，他們可以根據自己的喜好來給新產品和新技術取個代碼。不過，命名也不是天馬行空，有個前提，為了避免法律上潛在的風險，代碼名字的選用應該是地圖上可以找到的。

英特爾很多產品的開發部門都集中在加利福尼亞州(California)舊金山附近的矽谷以及俄勒岡州(Oregon)波特蘭市周邊，所以在這兩個地方工作的英特爾項目組都會以工作地周圍的地名，街道名，河流名，山名等等作為產品或者項目的代碼，它們在地圖上都可以找到。

當然，代碼的選用不限於這兩個州，項目的負責人也可以從自己家鄉的地圖或者其他地方地圖上可以找到的名字來作為代碼。在我印象中，中國團隊負責的一些項目就用過像Pearl River(珠江)，Yellow River(黃河), O'River(甌江)等等，因為項目是區域性的，也只是在內部溝通使用，所以眾多代碼並不為公眾知曉。

我特意查了一下，Nehalem其實是美國俄勒岡州波特蘭市的一個小小的衛星城。