【CPU】推土機三世能否翻身，Steamroller聚焦性能提升

[複製連結] 檢視: 863|回覆: 0

CANCERS

名望的勇者

電梯直達

1^#

發表於 12-9-5 11:56:46 |只看該作者 |降序瀏覽大字中字小字正體化简体化

　　AMD嘔心瀝血研發的“Bulldozer”推土機架構被譽為X86體係數十年來最大的革命，但是最終的測試中卻是出師不利，根本無法與Intel同代產品相抗衡，只能打性價比這張牌，甚至一度寄希望於微軟的執行緒調度補丁，但是打了補丁之後性能也沒有明顯變化。　　事後也有很多分析，包括工藝不成熟、軟體最佳化不足等等，最權威的解釋來自Anandtech，測試分析之後認為是推土機的分支預測及指令快取命中設計不夠好，導致了架構失利。
　　在這之後，AMD在今年的處理器及APU上開始使用第二代推土機核心--Piledriver，號稱IPC(每週期指令)性能比第一代推土機提高15%，Trinity APU所反映出來的CPU性能測試也一度帶來驚喜，但是最終的結果依然是聊勝於無，變化並不大。
　　下一個要期待的就是第三代推土機核心-Steamroller(壓路機)了，28日開幕的Hot Chips 2012會議上AMD CTO Mark Papermaster就公開了這一核心的相關訊息，而Anandtech網站也做了一番解析。

AMD處理器架構路線圖

　　目前第二代Piledriver核心的主要變化是在功耗降低上(更可能的原因是GF的32nm SOI工藝成熟了)，AMD稱活動狀態下平均減少10-20%，所以同樣的TDP功耗下頻率變高了，這一點在Trinity APU及剛剛報導過的FX-8350頻率達到4GHz上可以看得出來。
　　Pildriver的執行緒調度效率也改善了，此外還有指令域取及分支預測的最佳化，但是總體來看性能變化並不大。

Screen%20Shot%202012-08-28%20at%204.38.05%20PM_575px.png

　　Steamroller基本沿用了Bulldozer/Piledriver的架構設計，但在他們的基礎上全面進化。不過按照Intel的Tick-Tock戰略來看，Steamroller並不是“Tick(指工藝升級)”，因為28nm Bulk工藝跟32nm SOI工藝沒有太大區別，但是它是“Tock”架構升級，雖然大部分架構沒有改變，從某些角度來看Steamroller是介於工藝轉換與架構升級的兩個極端中。
前端改進
　　推土機/Piledriver最大的問題之一就在於共享了預取和解碼單元，這個問題可以從下面的表格來看：

　　Steamroller終於改變了這個弊端，每個模組中的內核都有了自己的4發射指令解碼單元，而且每個解碼單元都是並行操作而非之前那種每週期循環運作。雖然雙倍的解碼單元並不意味着雙倍的性能提升，因為4發射前端不可能總是100%利用，但它依然是Steamroller架構中最大的變化。
　　改用這個設計之後弊端也很明顯，功耗及核心面積都要上升，但是權衡之後這麼做還是值得的，而且這個不足可以從其他方面彌補，後面還會繼續講到。

Screen%20Shot%202012-08-28%20at%204.38.09%20PM_575px.png

　　Steamroller繼承了Piledriver分支預測設計，但是性能做了改進，特別是針對伺服器負載，而且分支目標緩衝器更大，這樣一來分支預測失敗的幾率就減少了20%。
執行單元的改進
　　AMD將Steamroller模組中的共享浮點單元更加合理化，FPU單元的執行能力並沒有變化，但是核心面積總體上降低了。MMX單元現在可以與128bit FMAC管線共享部分硬體。AMD並沒有提供太多介紹，只是說硬體共享只用於獨有的MMX/FMA/FP操作，因此並不會帶來性能懲罰問題。

Screen%20Shot%202012-08-28%20at%204.38.14%20PM_575px.png

浮點單元的改進

　　管線資源的減少被認為是功耗和麵積減少的主要原因。
　　整數單元的執行單元沒有變化，不過其他方面的改進依然提升了它的性能。
　　Steamroller架構中的整數和浮點單元寄存器檔案更大，雖然AMD沒有明確說明有多大。負載操作(2操作)也被壓縮了，因此物理寄存器檔案只需要一個入口即可，這樣可以提高寄存器檔案的等效大小。
　　調度視窗(scheduling windows )的大小也提升了，這樣可以更好地利用現有的執行單元資源。
　　儲存-載入(Store to load forwarding)好像也有提升，Steamroller在偵測互鎖、取消Load操作及從Store單元讀取數據方面做的比前兩代更好。
快取改進
　　共享的L1指令快取大小也提高了，不過AMD還是沒有實際說明。推土機使用的是每模組2路64KB L1指令快取，每個內核勢能使用一路，這樣一來推土機的每個內核使用的L1指令快取就比上一代的Phenom還要少，因此Steamroller增大L1指令快取很有意義。
　　AMD稱增大L1容量之後，指令快取的命中失誤率降低了30%，不過有關L1數據快取的設計沒有消息。
　　另外，雖然AMD不願意稱之為快取，但是Steamroller現在確實增加了一個解碼微操作隊列(decoded micro-op queue)，一旦X86指令解碼為微操作，定址和解碼操作就儲存在這個隊列裡。預取時，只要這個隊列裡有對應的定址數據，那麼Steamroller的前端就會關閉解碼單元，只用這個隊列來服務預取請求。這與SNB架構裡的decoded uop cache設計類似，當然看起來規模更小一些罷了。AMD並不願意公開這個隊列裡有多少微操作，只說它們對目前的指令命中率來說已經足夠大了。
　　L1到L2快取的介面也提升了，隊列變大，並改善了邏輯性。

Screen%20Shot%202012-08-28%20at%204.38.17%20PM_575px.png

　　最後，Steamroller在快取前端引入了動態大小的L2快取，可以根據快取負載及命中率的高低，Steamroller的模組可以1/4隔斷選擇使用多少L2快取，用不到的那些就會被關閉。AMD認為這一設計在移動客戶端的應用很有意義，比如視訊解碼時CPU只需要短時間工作而不需要太多的L2快取應用，這一設計就可以降低功耗，提升續航時間。可調快取不會提高性能(有一些連接延遲)，它的出發點主要是減少能耗。
　　Steamrollerz減少L2/L3快取延遲上沒有太大變化，根據AMD的說法，他們認為推土機架構中的L3快取延遲過高並不是問題，至少在修復上沒有列入高級優先權，而且消費級市場的處理器的L3快取通常比較少(Trinity、Llano上直接沒有L3快取)，而伺服器應用中對L3快取延遲又不敏感，因此L3快取延遲高低並沒有太大意義。
未來前瞻：高密度Libraries
　　這部分主要講未來的CPU設計了，而且與GPU相關，因為未來的AMD CPU設計會使用GPU那種高級自動化設計及高密度單元Libraries，簡單來說就是AMD未來準備進一步使用自動化的CPU設計，更少地減少人工電路設計。
　　這種設計的好處是功耗和核心面積更低，在32nm推土機FPU單元上使用了這種設計之後功耗和麵積減少了30%。不過缺點也不是沒有，頻率不夠高，高度自動化的設計達不到人工電路設計的頻率，不過AMD認為這也是值得付出的代價，雖然達不到最高頻率，但是每個操作的功耗會降低15-30%。

Screen%20Shot%202012-08-28%20at%204.38.31%20PM_575px.png

　　Steamroller上還看不到太多高度自動化設計，不過2014年的Excavator處理器上就會看到了。
總結：
　　終於到總結了。
　　與Bulldozer、Piledriver架構相比，Steamroller更像是一次全面的進化，因為第二代核心Piledriver的目標主要是節能，而Steamroller的重點在於性能。
　　Steamroller的成敗還要看GF明年的28nm Bulk工藝如何，紙面上的Steamroller看起來很美好，但是它還要面對Intel的Hasell處理器競爭，到時候才會有好戲看。

轉播0 分享0 收藏0

回覆使用道具檢舉

最後更新返回清單

帳號		自動登入	取回密碼
密碼			註冊

【CPU】 推土機三世能否翻身，Steamroller聚焦性能提升

CANCERS

【CPU】推土機三世能否翻身，Steamroller聚焦性能提升