硬科技:為悼念Intel NetBurst的失敗而刻下的墓誌銘 (中)

2018.07.26 02:10PM
2639

閱讀本文之前,請先參閱前情提要「為悼念Intel NetBurst的失敗而刻下的墓誌銘 (上)」。回歸正題,一般坊間媒體與電腦玩家,對Intel NetBurst微架構與Pentium 4家族處理器的刻板印象,不外乎「一昧追求時脈,忽略真實效能,造成過熱問題」,但假使事情真有這麼單純,Intel真的蠢到眼中只有時脈 (反觀同時期那時脈連1GHz都到不了的「儲君」Itanium),各位科科也不會看到這短期連載了。

打造高時脈處理器的關鍵

事實上,魔鬼藏在細節中,NetBurst是非常非常有看頭的酷玩意,有太多值得大書特書的驚人特色,否則某位前Intel院士也不必寫出厚達近1700頁的磚頭,以後大概也不會出現如此具有話題性和爭議性的處理器微架構了吧。真的要將NetBurst分析得很詳盡,恐怕沒個兩三萬字是搞不定的,也因此,筆者只挑比較核心的關鍵來談談。

首先,先回到原點,想打造一顆高時脈處理器,除了切深指令管線,縮短每個階段的延遲,還有哪些需要特別考慮的地方?

一般人對於同步化「管線 (Pipeline)」的傳統認知,不外乎將工作切割成幾個處理時間大致相同的階段 (Stage),每個階段中間塞入由時脈 (Clock) 控制的鎖存電路 (Latch) 或階段暫存器 (Stage Register),包含出入口,一個被分割成N個階段的組合邏輯電路 (Combinational Logic),就需要N+1個鎖存,每個階段一起運作。

在某個階段的工作尚未完成前,前一個階段不能送資料進來。管線所能執行的最高頻率,決定於延遲最長的階段。但同步化管線會遭遇晶片不同部位的時序有所偏差的時脈偏斜 (Clock Skew) 現象,鎖存電路與階段暫存器也會增加額外的延遲時間、電路面積與耗電量,不易設計線路結構更複雜的運算單元,並限制晶片的時脈與性能。

如果科科們還在這樣想,就落伍了,早在1969年,學術界就有高人提出「Wave Pipeline」的概念:打通整條管線的任督二脈,一個時脈內灌入兩組以上的資料,進入組合邏輯電路,使其像波浪般的自由流動,再藉由動態調整控制訊號延遲時間的緩衝器 (Adjustable Delay Buffer),使其不會前後相互干擾,處理器只要在「第幾波」可以在管線的出口「收割」運算結果即可,例如:加法器尚未輸出運算結果前,後面就偷偷塞進新的訊號。換言之,Wave Pipeline的理論最高時脈,決定於「最長與最短訊號延遲的差距」,堪稱某種程度的逆向思考全壘打。

雖然早在1960年代末期,Wave Pipeline就應用在開「非循序指令執行與預測執行」之先河的IBM 360/91大型主機的浮點運算器,但當電腦輔助晶片設計工具 (EDA Tool) 漸漸普及後,晶片設計者較能精確估算電路內每一個訊號的傳遞時間與位置,才讓Wave Pipeline慢慢流行,以便減少電晶體數量、縮小晶片面積、降低耗電量,並提高運作時脈。

根據已公開資訊,Pentium 4與Itanium 2是Intel首次採用Wave Pipeline的處理器,而後者更因此讓八階管線的Itanium 2,在相同180nm製程時,時脈遠超過十階管線的初代Itanium。

只需存放需要被執行的指令

其次,做深管線是一回事,有沒有辦法餵飽足夠的指令,那又是另一回事,況且當碰到分支指令,就需反覆進行「分支預測→擷取指令→解碼指令」這繁瑣的過程,計算記憶體有效位址、執行分支預測、TLB將虛擬位址轉換為實體位址、從快取或記憶體擷取可能位於不連續位址的指令、解碼指令,都會耗費時間,不利塞滿管線。為此實作龐大的複數指令解碼器,更會激增晶片成本,畢竟x86處理器除了控制單元,就是這裡特別的昂貴,也特別的耗電。

所以Intel釜底抽薪,旁徵博引當年被Fujitsu取消的SPARC64 V原始設計,將第一階指令快取改造成「依據分支預測機制而得知的程式碼執行順序,而排好排滿的的微指令 (uOp) 快取」,也就是熟悉Pentium 4的科科們,耳孰能詳的Execution Trace Cache,並只需存放需要被執行的指令。當然,Trace Cache也有內部的分支預測機制,這裡就不詳談了。

所謂的Trace,則意指「透過分支預測結果,而取得的基本程式區段 (Basic Block)」,無論這些指令如何散布於記憶體四處,但解碼後就一同循序的放在同一條Trace內,可大幅簡化指令讀取動作,讓被解碼後的微指令,源源不絕的灌入處理器的執行單元。NetBurst微架構的Trace Cache,每個時脈週期最多輸入三個微指令。坦白講,光看到這裡的份上,NetBurst的指令輸出率,實在說不上有多突出,也沒有比前代P6來得高明。

Trace Cache的明顯缺點

不過Trace Cache的缺點也很明顯。首先,假若發生分支預測錯誤,或所需要的指令並未在Trace Cache內,就必須重新啟動「標準」的指令擷取/解碼程序,再根據分支預測的結果,重新建立Trace,耗費大量時脈週期,也變相降低能耗效率。

其次,被解碼後的微指令,勢必比被編碼的指令長得多,也激增實際所需的SRAM容量。Pentium 4的Trace Cache的容量為12K (12288) 個微指令,命中率約等同於8kB到16kB的傳統第一階指令快取,但卻吃掉了高達80kB (180nm製程Willamette,有做資料壓縮) / 96kB (130nm製程Northwood) / 128kB (90nm製程Prescott) 的SRAM容量,在晶粒圖上非常的「搶眼」。

也難怪一直有人這樣認為:Intel用SRAM容量去「等價交換」所費不貲的複數指令解碼器。但問題來了,這是否真的「等價」嗎?以事後諸葛的角度來看,Intel最終仍逐步回到複數指令解碼器,並搭配小型化的微指令快取,設法降低啟動解碼器的機率,才是最有經濟效益又兼顧效能和功耗的手段。

不知不覺中,字數又破表了,那兩倍時脈整數運算兼位址計算單元、四倍時脈資料傳輸率系統匯流排、超執行緒、將執行完畢的回存直接載入執行單元 (Store-To-Load Forward) 的轉送機能、還有遭遇因缺乏運算元 (快取誤失、回存轉載入後發現記憶體位址誤判、無預期的暫存器相依和臨時無可用執行單元) 而引發微指令執行失敗的「重新啟動直到搞定 (Replay)」機制,都跑到哪裡去了?各位科科呀,你是第一天看這個專欄嗎? (下期待續)

回應 4

4 則回應

蘋果新聞
蘋果秋季發表會懶人包:iPhone 11、iPhone 11 Pro、iPhone 11 Pro Max、第七代iPad、Apple Watch 5
atticus Chevelle.fu 討喜小姐 Tandee Zero圈圈
8 天前