Sandy Bridge微架構的革新

上文中筆者介紹了Nehalem微架構中存在的一些問題，到了Sandy Bridge這一代，這些問題還存在嗎？下面我們就來詳細解析Sandy Bridge的微架構，并介紹相對于Nehalem微架構的改進。

前端：

分支預測和微指令緩存

分支預測、指令拾取、預解碼以及解碼這幾個部件組成了處理器微架構的Front-End前端部分。在Nehalem 微架構中，指令拾取和預解碼存在問題，在一些情況下會導致指令吞吐量過低，因此其前端是整個流水線當中最容易成為瓶頸的階段。Sandy Bridge沒有直接在指令拾取和預解碼階段進行改動，而是對整個前端部分進行了重新設計，通過革新的分支預測單元以及在解碼階段加入一個新的部件來增強整個前端部分的輸出能力，同樣達到了消除瓶頸的目的。

處理器的前端從L1 I-Cache拾取指令，在指令拾取單元沒有什么變化的情況下，Sandy Bridge的L1 I-Cache也有了些改進，提升了大型應用程序下的性能。首先，它從Nehalem的4路組關聯提升到了8路組關聯，從而降低了Cache Line碰撞的幾率，降低了頁面沖突；其次，L1 I-Cache對應的L1 ITLB也略微擴大，2M/4MB對應的TLB表項從Nehalem的7+7提升到了8+8（對每一個硬件線程提供8個表項），可以覆蓋更大的代碼地址空間。

分支預測是一個既能提升性能又能降低能耗的做法，成功的分支預測可以避免無謂分支代碼執行的性能、功耗損失。Sandy Bridge的分支預測單元在Nehalem的基礎上進行了完全的重造。通過對分支表結構的壓縮定義，BTB（Branch Target Buffer，分支目標緩存）在同樣容量下將保存的分支目標翻番，同樣，GBH（Global Branch History，全局分支歷史表）也能保存更多、更深的項目，總的來說，分支預測準確率將會進一步提升。

前端變化中作用更明顯的解碼器旁邊加入的uop cache（微指令緩存），這個部件和NetBurst微架構的Trace Cache作用非常相似，不過卻是經過了更多的調整和優化，并且更加簡潔。uop cache保存了已經解碼的微指令，并且更加接近處理器的后端，因此也可以被稱為L0 I-Cache。根據英特爾的說法，通常的應用當中其命中率可以達到80%，在命中這個緩存之后，包括復雜的解碼器在內的其它前端部件可以關閉以節約能源，而由uop cache本身輸出指令。這個設計可以很明顯地降指令拾取低延遲乃至分支懲罰，讓前端可以在更多的時間內處于持續輸出4 uop/cycle的狀態，這很大程度消除了Nehalem前端的瓶頸。

后端：

物理寄存器文件架構

Front-End前端緊接著的是Back-End后端部分，Sandy Bridge在后端部分也有了很大的變化，其中一個變化來自于寄存器文件的變遷。在之前，我們介紹了Nehalem微架構采用的RRF（Retirement Register File，回退寄存器文件）存在的會導致寄存器讀停頓的問題，Sandy Bridge通過采用了PRF（Physical Register File，物理寄存器文件）結構來消除了這個問題，和前面的uop cache一樣，PRF的設計也是從NetBurst架構借鑒而來。幾乎所有的高性能處理器都采用了PRF的方式。

在Nehalem微架構當中，ROB（ReOrder Buffer，重排序緩存）順序保存了所有uop及其所有的重命名寄存器的數據和狀態，架構寄存器則保存在RRF當中。在Sandy Bridge的PRF上，ROB不再保存重命名寄存器的數據，取而代之的是保存多個指向PRF的指針，架構寄存器包含在RRF當中，通過狀態位來標識。

物理寄存器文件有什么好處？首先，它消除了舊有的寄存器讀停頓造成的瓶頸，現在它不再受限于RRF三個讀取端口的限制，所有不同寄存器的內容都可以同時進行讀取，不會再引起流水線停頓。其次，物理寄存器文件消除了寄存器間數據的復制和移動，而只需要更改指針的指向即可，這節約了大量的數據移動能耗，特別是在Sandy Bridge的AVX指令集支持更多的操作數以及支持的最大寄存器寬度翻倍的情況下。最后，ROB從保存數據變成保存指針導致了結構上的簡化，從而增大了ROB的容量，進一步提升了處理器亂序執行的性能。

Sandy Bridge的ROB從Nehalem的128項提升到了168項，PRF物理寄存器文件包含了兩個部分：每項64bit 、一共160項目的整數寄存器文件和每項256bit 、一共144項目的浮點寄存器文件，并且PRF是每個硬件線程各自一份。在Sandy Bridge架構當中，還增加了一個硬件監測機構，在使用SAVE/RESTORE指令進行線程切換或者虛擬機切換的時候，可以僅僅恢復/保存線程所使用到的寄存器，而不是恢復/保存所有的架構寄存器，從而節約了上下文切換的時間，這可以提升處理器運行大量線程和多個虛擬機的能力。

后端：

存取單元

微指令經過重命名階段和讀取PRF數據之后進入Reservation Station保留站，通過統一的調度器安排發射到6個不同的執行單元之中。Sandy Bridge的Reservation Station容量從Nehalem的36項目提升到了54項目，增加了50%，亂序執行窗口的擴大可以提升處理器的亂序執行能力。

Sandy Bridge的執行單元也有了很大的改進。執行單元包括計算單元以及存取單元，這兩個都變化甚大，不過這里我們先介紹存取單元的變化，因為之前介紹過Nehalem 微架構在這方面是個潛在的瓶頸。計算單元的改進留到下一篇文章中再介紹。

Sandy Bridge架構和Nehalem一樣具有3個存取端口，Store端口維持不變而Load端口的數量提升到了兩個，并且這兩個Load端口的AGU地址生成單元均能生成Store操作使用的地址。Load端口翻番在某種程度上是為了適應Sandy Bridge 處理器新增的AVX指令集帶來的256位計算能力，因為每個Load端口的寬度是128位。然而，現有的各種應用也可以立即從中獲益，因為Nehalem微架構的Load端口僅占所有執行單口的1/6，而Load操作通常可以占據uop當中的約1/3。Sandy Bridge的雙Load端口可以每個時鐘周期進行兩個128位Load操作，消除了上一代的瓶頸，工作起來也更為靈活。

和Load/Store單元連接的MOB（Memory Ordering Buffer，內存排序緩存）也得到了增強，MOB和前面的ROB一起屬于將亂序執行和順序回退連接起來的重要部件。在MOB當中，Load緩存從Nehalem的48項目提升到了64項目，提升幅度為33%，Store緩存從32項目略微提升到了36項目。Sandy Bridge的MOB一共可以容納100個訪存操作，這些數據操作均為256位寬度。

和Load能力翻倍配對的是L1 D-Cache的增強，它的帶寬提升到了48字節，也就是384位，比以往的32字節提升了50%，以同時支持兩個128位的Load和一個128位的Store操作。搭配的L1 DTLB據說也有所改進，增加了4個支持1GB頁面的項目，以進一部消除Nehalem微架構在面對海量內存應用下的性能問題，這4個大頁面DTLB項目應該是全關聯的，其它的L1 DTLB則應該維持4路關聯不變。

在L2 Cache方面，Sandy Bridge相對Nehalem沒有太大的變化。

可以看到，通過將Nehalem 微架構和NetBurst微架構進行融合，引入NetBurst上的微指令緩存和物理寄存器文件架構，并改進Load/Store單元和L1 D-Cache帶寬設計，Sandy Bridge消除了上一代Nehalem微架構存在的比較明顯的三個瓶頸，還順帶獲得了更多的附加增益。Sandy Bridge在整個流水線的方方面面都得到了改進，然而還有一個很重要的部分沒有被提及：運算單元，這個部分的變化和Sandy Bridge引入的AVX指令集緊密聯系，請看下回繼續分解。