時空背景
自打 AMD Zen 3 釋出後,Intel 感受到的壓力是與日俱增,桌面、伺服器以及筆記本市場都受到來自 AMD 產品矩陣的衝擊。不僅於此,相對於上市的產品而言,Intel 面臨的另一個困境是製造工藝上已經不再佔優,效能耗電比競爭力不再,這使得 Intel 或者說 x86 陣營得以在主流 PC 不敗的地位遭受前所未有的衝擊。例如 Apple 正逐漸切換到採用臺積電生產的 Apple Silicon 處理器,這對 Intel 來說是一個非常危險的警號。
我們都知道,Intel 本質上是一家工廠,同時也是美國目前為數不多的垂直大型晶片製造業龍頭,是高階製造業中的重中之重,當自己生產的產品也被本國長期合作的企業放棄時,那就是到了非改不行的地步了。
Intel 當前最大的問題是製程,由於製造工藝方面出現了落後於競爭對手代工廠的情況,因此擺在 Intel 面前的最大挑戰首先是如何儘快採用更先進的製程,以及如何從架構著手讓效能/耗電比指標實現逆轉勝。
相比三年前的了無生趣,PC 正迎來一場史詩級的重新提速,這是一場曠世的防守與反擊博弈,如今,這場史詩級的博弈正徐徐展開其第二篇揭幕戰的序章。
Intel 歷史上也出現過產品部分競爭力不敵對手,那是在 AMD K7/K8 vs Intel Pentium 4 的時代,距今差不多 20 年,幸運的是,Intel 趕上了筆記本崛起的浪潮,憑藉 WiFi 和 Core 架構成功卡位並在隨後的桌面大戰中憑藉 Conroe 收復失地。這說起來好像化解得挺輕鬆的,但是當年的動靜可是非常大,以至於出現了 Intel CEO 當眾下跪的局面。
來自 Intel 以色列海法團隊的 Yonah 和 Conroe 是扮演救主的重要角色,前者讓 Intel 把筆記本市場牢牢掌握在直接手裡,後者則是一洗 Netburst 架構在桌面市場的效能/耗電頹勢。
如今,這支 1974 年就成立的團隊再次出擊,它們這次祭出的是代號為 Alder Lake 的第十二代酷睿處理器。
10 納米制程的全力出擊——Alder Lake 架構概況
對於研發階段的產品或者技術冠以各種架構代號是司空見慣的,曾經在 Intel 任職 20 年的 Francois Piednoel 將將取架構代號的原因歸結為兩個:保密以及讓媒體大驚小怪,當年 Intel 曾經於 IDF 密室內在媒體不知情的情況下演示過 Conroe,由於遮蔽了其中的運算單元,以至於媒體以為跑的是更好的 Yonah,後來 Intel 還把這個“更好的 Yonah”發給 OEM 和 ODM,大家渾然不知手頭測試的是 Intel 全新的下一代處理器。
相對於多年前名稱差別較大的代號名稱,Intel 現在的架構代號大都以 Lake 或者 Cove 結尾,要區分這麼多 cove 和 lake 對讀者來說是相當困惑和考驗記憶力的事情。
Alder Lake 架構是 Intel 歷史上第一個實際上市的混合核心架構,在這之前該公司曾經有一個代號 Lakefield 的 x86 混合核心專案。Lakefield 是一個移動 CPU,大小核分別是一個 Sunny Cove(在 Tiger Lake 或者說十一代移動酷睿處理器中採用)和四個 Tremont,包括微軟的 Surface Go 和三星的 Galaxy Book S 都曾經被表示會採用該處理器。
Lakefield 採用堆疊晶片封裝,其中的 Compute Die 或者說計算晶片採用 Intel P1274(10 奈米)製程,裡面的大核 Sunny Cove 核心面積大約是 4.5 平方毫米,而小核 Tremont 只有 0.88 平方毫米,兩者面積存在巨大差異,按照 Intel 的說法,每枚小核的效能相當於Sunny Cove 的七成。由於面向的是 Intel 一向競爭力最弱的移動裝置,因此 Lakefield 在 Intel 的產品線中並不起眼,乃至它被取消了也沒有引起什麼波瀾,存在感很低。
名字取自美國西部華盛頓州一處湖泊的 Alder Lake 滿血版具備 8 + 8 = 16 個核心,其中 8 個高效能核心(P-Core,核心編號 0-7)的代號是 Golden Cove,另外 8 個高效核心(E-Core,核心編號 8-15)的代號是 Gracemont。
Intel 將這種大小核混編的技術命名為 Intel Hybrid(英特爾混合)或者 Hybrid Computing Architectures(HCA),以便和 ARM 的 big.LITTLE 區分。
在 Intel 提交的 perf(linux 下的效能特徵分析工具)補丁裡,P-Core 屬於 Core 型別,E-Core 屬於 Atom 型別,很多效能計數器事件是分立的。例如,想要採集 IPC 資料的話,採集的指令效能事件需要單獨列明,例如 cpu_core/instructions 和 cpu_atom/instructions,當然如果是 LLC(第三級快取)、能源這類事件則是統一的。
從處理器的整體架構來看,Alder Lake 相當於傳統 Core 系列處理器加掛了兩個四核 Atom 核心簇,每個 Atom 核心簇共享一塊 L2 Cache,然後分別掛在 Ring bus 上,與 P-Core 一起共享 L3 Cache。
在核心拓撲關係工具 lstopo 中 Core i9 12900K 呈現的層次關係如下:
和扮演救火隊員角色的 Rocket Lake 相比,除了 GPU 基本保持不變(都是 Xe-LP 架構,型號名稱從 UHD750 變為 UHD 770,GPU 頻率有大約 400MHz 提升)外,Alder Lake 在 CPU 核心微架構(P-Core、E-Core)、PCIE 匯流排、DMI 匯流排、記憶體子系統上都有很大的變化。更重要的是,RKL 使用的是 Intel 祖傳 14nm 製程,而 Alder Lake 則是 Intel 7 或者更準確的說法——10nm Enhanced SuperFin(10ESF)製程,這是 Alder Lake 得以實現的基礎。
Golden Cove 和 Gracemont 雖然都是 x86 指令集處理器,但是在微架構層面上存在巨大差別,前者具有更深、更寬的流水線,頻率設定較高,強調高效能;後者的角色按照設計理念是做一些輕體力活為主,強調低能耗,Intel 為此還專門加入了一個名為 Thread Director(執行緒導向器)的硬體執行緒導向器,這個導向器的目的就是把各種執行緒按照其負荷遞交給不同型別的核心。
Golden Cove 雖然屬於十一代筆記本酷睿(Tiger Lake)裡 Willow Cove 的升級,但是它在某些方面都有巨大的變化,例如亂序指令視窗方面,ROB(重排序快取)的大小可能是 x86 史上最大的增幅,充分利用了新制程電晶體密度提升帶來的好處。按照 Intel 的說法,Golden Cove 的 IPC(每週期指令)效能相較上一代(Willow Cove)提升了 19%。
Gracemont 主打低能耗,但是本身的效能還是可以的,它屬於 Atom 陣營裡的第四代亂序執行架構,效能並不亞於三年前的主流桌面處理器。
更多的核心以及更寬的指令執行能力帶來的問題是記憶體頻寬需求增加,Intel 為 Alder Lake 配備了同時支援 DDR4 和 DDR5 的記憶體控制器,前者的價格相對較低,而後者具備更高的記憶體頻寬。
在周邊互聯能力上 Alder Lake 提供了 PCIE 5.0 x16 和 PCIE 4.0 x4,前者可以提供合計 64GB/s 的頻寬,後者可以提供合計 8GB/s 的頻寬;與北橋或者說 PCH 的連線匯流排也從之前 RKL 的 DMI 3.0 x8 提升到了 DMI 4.0 x8,,每條 DMI 4.0 通道可以提供 16GT/s 的傳輸速率,因此 Alder Lake-S 和 Z690 晶片組之間的頻寬可以達到 64GB/s。
桌面版或者說 Alder Lake-S 搭配的 GPU 依然是 Rocket Lake 裡的 Xe-LP,擁有 32 個 EU。每個 EU 是一個 FP/INT SIMD8(相當於 NVIDIA 的 CUDA sub-core)的運算單元,每個週期可以執行 8 個 FP32 FMA 指令或者說 16 個浮點操作,合計就是每個週期可以跑 512 個 FP32 浮點操作。像 Xe-LP 這樣的核顯效能可以滿足很多應用場合,特別是在現在顯示卡溢價讓人難以接受的情況下,Xe-LP 表現出來的效能還是讓我感到很滿意的。
值得一提是,現在 Adobe Premiere Pro 2022 已經提供了 Intel Xe 架構系列 GPU 的 HEVC 4:2:2 10-bit 硬體解碼支援。
這個支援是用 OpenCL 介面呼叫 Intel 的影片解碼器實現的,只要你使用上包含 Xe GPU 的 Intel CPU(臺式酷睿十一代以上、筆記本酷睿十代以上)來跑,都能獲得絲滑般的時間線流暢拖動效果,對於 PC 影片編輯使用者來說,這意味著不用再羨慕蘋果 M1 電腦了。
不過比較遺憾的是,這個特性目前尚未有 DXVA 介面解碼器軟體提供,這類影片目前在播放器裡依然無法實現硬體解碼回放。當然,也許某天例如明天,LAV filter 就把 Intel 的 HEVC 4:2:2 10-bit 調出來了。
Alder Lake 提供了 DDR5 和 PCIE 5.0 這兩個 “5” 系新技術,前者對於改善多核效能並且對核顯效能會有一定助益,而 PCIE 5.0 主要用武之地是顯示卡和 NVME SSD,但是目前對大部分普通使用者來說,這兩個 5 系技術帶來的效能提升在現實中不是那麼容易察覺。
由於集成了多達 16 個核心以及大量高頻寬部件,Intel 為 Alder Lake 的內部互聯提供了 Tiger Lake 同款的 1000GB/s 的雙環路互連匯流排,理論上滿載的時候每個核心可分配到的頻寬是 62.5GB/s,當然這只是理論值,因為全核跑向量計算的時候記憶體頻寬更容易成為瓶頸。
我用 MicrobenchX 的 C2C 測試了核心時延:
從 C2C 時延測試來看,Alder Lake 的核心間時延要比 Zen3 高不少,其中 e-core 的 4 核簇內部之間似乎存在較高的時延,這有點出乎意料,要知道它們是有一個 L2 cache 共享資料。
Intel 為 12 代酷睿提供了全新的 LGA1700 插座,這似乎不是什麼大的問題,過去這麼多年裡,Intel 更換插座基本上就和換件衣服一樣說換就換,大家早有心理準備,很多散熱器廠商都表示可以為使用者提供相應的底板升級售後服務。按照目前的訊息,這個 LGA1700 除了 Alder Lake 外還會在之後的至少兩代產品繼續沿用。
接下來讓我們看看 Alder Lake 混合架構裡兩種核心的細節。
微架構——Gracemont
如果不考慮 Larrabee 這個物種的話,Intel 的 x86 產品線可以分為兩大品牌系列,也就是 Core 和 Atom,分別對應高效能和低耗電。第一個 Atom 誕生於 2008 年,比 Core 晚了兩年。當時正值移動裝置迅速崛起,Intel 全副身家都押寶 x86,Atom 則是其中被寄予厚望的品牌之一。
由於缺乏良好的生態以及配套服務,Atom 最終在手機市場敗下陣來,不過這個品牌並未消亡,由於 x86 在工業領域具備非常好生態,因此 Atom 都被做成工控機、路由器、NAS 等不需要高效能核心的應用場合。
最初的 Atom 微架構代號是 Bonnell,之後有名為 Saltwell 的衍生微架構,這兩代都是屬於順序執行流水線,雖然省電,當時效能真的一般。
第三代 Atom 微架構名為 Silvermont,引入了亂序執行,衍生微架構有為 Airmont。
自此開始,所有的新 Atom 微架構代號都帶有 "-mont" 的字尾。
我們把 Sivermont 視作第一代亂序執行 Atom 微架構,之後分別有 Goldenmont(衍生微架構為 Goldenmont Plus)、Tremont 以及現在 Alder Lake 裡的 Gracemont,因此 Gracemont 已經是第四代亂序執行 Atom 微架構。
Alder Lake 是第一個採用 Gracemont 核心的晶片架構,滿血的 Core i9 12900K 包含有 8 個 Gracemont 核心,每 4 個 Gracemont 構成一個核心模組共享 2MB L2 Cache。
圖源:wikipedia
在 Alder Lake 中,每四個 Gracemont 組成一個 Atom 簇,共享一塊 2048 KiB 大小的 L2 Cache,每個 Gracemont 擁有 64 KiB L1 指令快取記憶體(兩倍於 Tremont)和 32 KiB L1 資料快取記憶體。
比較特別的是,Gracemont 引入了名為 OD-ILD 的按需“指令長度”預解碼器設計。眾所周知,x86 屬於 CISC 或者說複雜指令集計算機,其指令長度可以是 1 個位元組到 15 個位元組,進入解碼器之前需要確定指令的邊界或者說長度。Gracemont 在L1 指令快取裡存放了指令長度資料,可以在指令第二次拾取時繞過預解碼階段,直達指令解碼器前的指令佇列上,這樣的設計可以節省部分週期和耗電。
Gracemont 採用了雙解碼器簇的設計,每個解碼器簇各有三個簡單 x86 指令解碼器。雖然看起來一共有六路解碼,但是兩個解碼器簇合計只能向下遊輸出 5 個 RISC 風格的微操作。與之相比,Gracemont 的直系上代微架構 Tremont 也具備一樣的雙 3 路解碼器,但是隻能做到輸出 4 個 RISC 風格微操作。
按照之前 Tremont 微架構釋出時候的說法,這種雙解碼器簇對於 Atom 來說效果比 Core 裡使用位操作快取記憶體(micro-ops cache)的做法更好,既能做到 6 路指令解碼又能降低芯片面積。
從較大的 L1 指令 Cache 到雙解碼器簇設計來看,Intel 是下了大功夫來改善 Gracemont 的前端瓶頸,原因是它的後端微架構實在有點炸裂。
在後端方面,Gracemont 的重排序快取可以容納 256 條目,可以向執行單元同時派發 5 個微操作,相比之下上一代的 Tremont 指令視窗是 208 條目,可以向執行單元同時派發 4 個微操作。在執行單元埠數方面,Gracemont 和 Tremont 分別是 17 個(12 個整數 + 5 個浮點)和 10 個(7 個整數 + 3 個浮點),指令並行能力有所提升,事實上如此眾多的執行埠也是 Gracemont 微架構中最讓人驚訝的地方。
e-core 和 p-core 同時開啟的時候,指令集支援能力是完全一樣的,可以支援 AVX2 或者說相當於 Haswell 的級別。
但是 p-core 或者說 Golden Cove 其實是內建了 AVX-512 指令支援,當我們把 e-core 關閉後,現在的 BIOS 能夠讓 p-core 那邊的 AVX-512 開啟。
關閉 e-core 後,uncore 時鐘頻率(原為 3.6GHz)也會得到提升,例如在 Windows 下會 uncore 提升到 4.7GHz,而在 Linux 下 uncore 提升幅度會低許多,只有 3.8GHz。
既然談到了 p-core,那麼我們直接轉到 p-core 的架構討論吧。
微架構——Golden Cove
正如我們前面所說的那樣,Golden Cove 物理上具備 AVX-512 指令集的硬體支援,但是其啟用條件是要在 BIOS(新版)裡關閉所有 e-core,這意味著目前的 p-core + e-core 組合對於希望能實現 AVX512 的使用者來說未必是最佳選擇,英特爾倒是提供了 6P + 0E 的物理純 p-core 版本,例如 Core i5 12400。
讓我們從流水線的前端(取指和解碼)說起。
Golder Cove 的 L1 指令快取記憶體和上一代的 Willow Cove 相比未有變化,都是 32 KiB,但是與之關聯的指令頁表快取(I-TLB)是做了升級的,其中 4K 頁表的條目數從 128 增加到 256,2M/4M 頁表的條目數從 16 提升到 32。
在分支預測器方面,Golden Cove 的目標分支快取(BTB)條目數增加了一倍多,從 5K 增加至 12K,相比較之下,AMD 的 Zen 3 不過是 6.5K、Willow Cove 是 5K。
更大的 BTB 原因很簡單,Golden Cove 的 x86 指令解碼器達到了 x86 史上之最——多達 6 + 1 個,而它的主要對手 Zen 3 只有 4 個,更是兩倍於 Willow Cove 的兩倍。
為了降低更多指令解碼器帶來的耗電和時延問題,Intel 將微操作快取(micro-ops cache)的大小從 Willow Cove 的 2.25K 條增加到 4K。按照 Intel 的說法,由於具備微操作快取設計, Golden Cove 的解碼器有 80% 的時間都是處於時鐘門控(clock-gating,單元時鐘被關閉,相當於熄火)狀態,有效降低了這部分電路的動態功率。
為了餵飽 6 個解碼器,Intel 把指令拾取頻寬從每週期 16 位元組提升了一倍達到 32 位元組,與 Zen 3 持平。
在微操作快取記憶體方面,現在可以每週期傳送 8 個微操作,同樣達到了對手 Zen 3 的水準,相比之下 Willow Cove 只做到了 6 個微操作。
位於解碼器和微操作快取記憶體下游的微操作佇列(uop-DQ,或者說分配佇列——Allocation Queue)如今也被加大了:
對於單執行緒應用,微操作佇列可以存放 144 個(Willow Cove 是 70 個);
對於支援 SMT 的應用微操作佇列則只是增加了多了兩個(70->72)。
Golden Cove 的排程器具備 6 個分配埠以及 12 個執行埠,相比之下上一代的 Willow Cove 是 5 個分配埠和 10 個執行埠。
AMD 的 Zen 的排程器採用了類似 Apple M1 那樣的整數、浮點分離式設計,可同時排程 8 條整數指令和 6 條浮點指令。某種程度上,Zen 系列和 Apple M1 這方面長得有點很像,都採用了分離式排程器的設計。
在 ROB 重排序快取方面,Golden Cove 達到了 512 條目,AMD Zen 3 是 256,Willow Cove(Tiger Lake,10nm)和 Cypress Cove(Rocket Lake,14nm+++)都是 352。
Apple M1 的 ROB 有媒體說高達 600 個,但是也有人(Dougall Johnson)認為其 ROB 採用的是一種合併式的新設計——大約有 330 條目,但是每個條目裡可能有多達 7 個回退的微操作,這使得 Apple M1 在使用不同的測試條件下能達到的大小可以是 623、853 甚至 2295 個。
在後端執行單元方面 Golden Cove 的變化相對較少,主要是浮點單元方面,首次在 x86 處理器上實現了兩個快速浮點加法單元,相比之下 AMD 的 Zen 3 和 Intel 的 Willow Cove 都缺少快速加法器。
此外,我們前面提到過 Alder Lake 是支援 AV512 指令集的,但是需要關閉了 e-core 後才能開啟 AVX-512,我們有理由相信 Intel 是經過深思熟慮後才決定把這個耗費了大量電晶體的單元給遮蔽掉的。
在整數流水線方面,Golden Cove 引入了新的埠(Port 10),使得 Golden Cove 一共有 5 個演算法邏輯單元(ALU),這五個 ALU 都可以實現單週期執行 LEA(返回有效地址)指令,這樣的設計讓 Golden Cove 和 Zen 3 在整數後端方面達到接近的水平。
在記憶體子系統方面,Golden Cove 增加了一個 Load(載入)埠,合計可以每個週期跑 3 個 256 位 Load 操作(或者兩個 512-bit Load 操作),以及可以跑兩個 Store 操作。和 AMD Zen 3 是每個週期三個 Load 操作或者兩個 Store 操作相比,Golden Cove 要強上一些。
在 Load/Store 的亂序執行潛力方面,Golden Cove 的 Load/Store 佇列分別是 128 和 72(AMD Zen 3 從測試結果來看是 112 和 64,但是 AMD 方面表示實際的大小是 44 和 64,也許和內部的一些最佳化有關)。
上面就是 Intel 方面提供的 Gracemont 和 Golden Cove 微架構的資料,接下來,我們會進行一些底層測試,更進一步瞭解微架構的一些細節。
測試平臺
CPU:Intel i9 12900K、Intel i7 11700K、AMD Ryzen 7 5800X、
主機板:
LGA1700:
DDR4:ASUS TUF GAMING Z690-PLUS WIFI D4
DDR5:ASUS ROG MAXIMUS Z690 HERO
LGA1200:ASUS TUF GAMING Z590-PLUS WIFI
AM4:ASUS ROG STRIX X570-E
記憶體:
DDR4:3600MT/s,16 GiB x4 或 8 GiB x4;
DDR5:5200MT/s,16 GiB x4
顯示卡:NVIDIA 獨顯(在微架構測試中不重要)
硬碟:256GB SSD
作業系統:
Linux:Ubuntu 21.10 + Kernel 5.15RC7/
Windows:Windos 10 21H2
底層測試——指令吞吐測試
我們在這裡使用的都是網上現成的底層測試軟體,它們都有原始碼提供,如果沒特別提及的,大家也都可以循名稱在網上搜索到。
為了便於對比和觀察,如果不加說明,底層測試的頻率都是鎖定在 4GHz,關閉超執行緒,徹底禁止 Windows Defender,Windows 電源管理設定為效能模式,Linux 電源管理設定為 performance 模式。
MicrobenchX.IPC
這是 MicrobenchX.IPC 1.03 版的測試結果,這裡的 P-core 測試結果我加入了 AVX-512 的資料供大家參考。
測試結果扼要:
1、Golden Cove 的第五個加法器提供了 23% 的提升;
2、和 Zen3 相比,Golden Cove 的 128-bit 向量整數加法、64-bit 整數除法、256-bit 向量整數乘法、128-bit 向量整數乘法存在一定的差距;
3、雖然 Gracemont 具備超多的執行單元埠,但是和 p-core Golden Cove 實際的底層 IPC 差距還是相當明顯的。
4、從微架構角度來看,Golden Cove 屬於 Tiger Lake 中 Willow Cove 的升級,但是它在桌面領域對應的前代產品則是採用 Cyperss Cove 微架構的 Rocket Lake。和 Cypess Cove 相比,Golden Cove 的 AVX512 浮點加法和減法效能快了一倍,整數+浮點混合指令快了 32%,不少指令都有相對顯著的提升。
底層測試——流水線深度探測
流水線深度和處理器頻率延伸能力、分支預測失敗懲罰有密切關係,不過目前的處理器廠商一般都不公佈相關的資訊,這是有原因的。
現在的核心流水線設計異常複雜,不同指令流向經過的流水線工位數可能是不一樣的。
為了探測 Golden Cove 的流水線深度,我使用了多種程式碼來測試。
下表中的左側是以虛擬碼方式提供分支程式測試片段,以第 7 個測試(Test 6)為例:
Test 6, N= 1, 8 br, MOVZX XOR ; if (c & mask) { REP-N(c^=v[c-256]) } REP-2(c^=v[c-260])
這段虛擬碼包含了一個 MOVZX 記憶體載入操作指令,根據處理器的不同,它可能需要額外的 5 到 6 個週期(可能更少)來執行,在支援亂序執行、亂序 L/S 的處理器中,這個動作佔用的流水線工位通常會被掩蓋掉。
關於一些表格中的指令時延,例如 MOVZX,我們做了另行的測試。
在 Golden Cove 上錄得的資料為 0.8 個週期,Zen3/Zen2/Zen+ 都是 1 個週期,Cypess Cove 是 0.9 個週期。XOR r64, r64 指令方面,Zen 3 是 0.2 週期,Zen2/Zen+/Zen1 是 0.3 週期。Test 指令方面,除了當年 Pentium 4 時代涉及訪存的時候會有兩週期時延外,這裡測試的處理器都是 1 個週期時延。
從測試結果來看,在分支預測失敗的情況下,Golden Cove 的懲罰週期大約是 13 到 26 個週期,其中最普遍的是在 18 週期左右,Gracemont 懲罰週期大約是 15 到 23 個週期,其中最普遍的是在 16 週期左右。據此我們估計 Golden Cove 的等效流水線深度大約是 18 級工位,而 Gracemont 是 16 級工位,由於 Golden Cove 具備可節省取值、解碼階段的微操作快取,實際的流水線深度可能要接近 22 級甚至更深,Gracemont 由於採用了可以繞過預解碼階段的按需指令長度解碼器設計,因此其實際流水線可能是 17 級。
底層測試——取值、解碼能力測試
取指、解碼能力測試
處理器的流水線可以分為取指、解碼、執行、寫回四個工位,其中前端(front-end)是指取指和解碼,執行和寫回被稱為後端(back-end)。
對於現在的超標量流水線處理器說,每個週期可以執行多條指令,前端需要為後端提供匹配的取指、解碼能力,同時為了保證流水線閒置執行單元不浪費,人們還引入了分支預測單元,根據預測結果決定是否將下一條指令先派發給後端閒置的單元執行,待分支確定是否選中後再決定是否保留計算結果或者重置流水線。
op cache 也被稱作 micro-op cache 或者 L0 I-Cache,它裡面存放的是若干段處理器認為會被近期重複使用的微操作(micro-ops),所謂的微操作是 x86 處理器為了簡化後端設計引入的處理器本機指令,是已經經過解碼器解碼的長度固定的本機指令。
在迴圈語句裡的指令在很多情況下都是不斷重複的,這些指令以微操作的方式放在 uop cache 後,後面重複執行這些操作的話,就無須經過解碼器這個工位,直接發往後端的佇列裡等待發射執行。
uop cache 在 x86 上的原型是當年 Pentium 4 引入的 Trace Cache,Trache Cache 需要消耗大量的芯片面積,但是這是提高超長流水線架構處理器效能重要的一環。在 Pentium 4 終止後,Trace Cache 的瘦身版就以 uop cache 的形式引入。
要想了解處理器的能力,取指、解碼是我們首先想要了解的,在這裡我們使用 nop、sub、prefix cmp 8 等三種指令來做測試,其中 nop 指令是看空操作指令,x86 的 nop 長度是 1 個 位元組,sub 是減法指令,和加法指令 add 一樣在 x86 中指令長度都是兩個位元組,prefix cmp 是 8 位元組或者說 64 位長的指令。
我們圖表中給出的 prefix cmp 測試結果基於這樣的指令:
[rep][addrovr]cmp eax, 0x7fffffff)
圖表橫座標標註使用的是十進位制資料格式,66KB 對應的是 64KiB,34 MB 對應的是 32 MiB,如此類推。大家要是有辦法在 Excel 裡實現二進位制資料格式的話不妨告知一下。
Golden Cove 的測試結果實在有點讓人感到驚豔。
首先,單位元組的 NOP 指令看來是已經在很大程度上被 Intel “最佳化”了,解碼頻寬資料顯示此時達到了每個週期 7 位元組或者說 7 IPC,並且能一直維持到 L3 Cache 邊界,我相信 Intel 對 NOP 這種什麼都不幹的指令做了一些特別的處理。
Gracemonmt 的 NOP 表現也是不錯,其 6.x IPC 效能可以維持到 8KiB 的水平,並且在 128KiB 邊界處也能維持到接近 6 IPC 的水平。
相較之下,去年曾經閃耀奪目的 Zen3 一下變得有點跟不上形勢了。
我們使用的測試工具並非什麼流行測試軟體,Intel 應該不會投入資源特別最佳化,這個測試結果純屬因為微架構內部的一些新設計帶來的。
Golden Cove 的 sub 或者說減法指令解碼頻寬能在 4KB 邊界處維持每週期 15 位元組,sub 指令是雙位元組的,這意味著此時的解碼效能至少有 7.5 IPC,這應該歸功於 4K 條目大小的微操作快取。
在接下來的更大區塊裡,Golden Cove 依然能維持 6IPC 的解碼效能,其範圍達到了 16 MiB,從程式設計師的角度,對於雙位元組指令 Golden Cove 在取指工位上具備比較真實的每週期 16 位元組能力,這個能力可以維持到從 L3 Cache 取指。
Gracemont 在這裡墊底了,在 8KiB 範圍內只有 3 IPC 的水平,相當於 Golden Cove 的 1/5。
從測試結果來看,Golden Cove 對於更復雜指令(prefixed CMP-8)的解碼能力是有顯著提升的,可以在 32KiB 的範圍內維持每週期 50 位元組的解碼頻寬結果,相當於每個週期 6.25 IPC。
Gracemont 在這個測試中表現不遜色於 Zen3,能在 12KiB 範圍內維持 4 IPC 的水平。
底層測試——分支預測器
分支預測維持流水線充盈的重要效能手段,但是對於現在的長流水線處理器來說,分支預測失敗的話對效能懲罰會非常高,因為這意味著運算結果要被拋棄並且流水線要被洗刷,即使是 1% 的命中缺失對效能來說也是非常致命的,當然這也意味著多增加 1% 的命中率收益會非常大。
現在的處理器在內部提供了效能計數器,可以讓我們瞭解處理器執行某個程式消耗的週期數、指令數、分支指令數、分支命中失敗指令數等資料,我這裡在 Linux 下對 CPU2017 的 intrate 測試包進行了分支預測資料採集,結果如下。
我們對 Alder Lake 的 Golden Cove 和 Gracemont 編譯時使用的架構代號都是 Alder Lake,目前沒有專門的 Golden Cove 和 Gracemont 架構開關。
從測試記過來看,我認為 Golden Cove 的分支預測器在整數應用中的準確度是稍遜色於 Zen3 的,不過在浮點應用方面要好些,不過浮點應用的分支指令佔比要低很多。
底層測試——亂序執行視窗特性探測
很多亂序執行處理器都採用了名為 Re-Order Buffer(重排序快取)的技術,使指令在亂序執行後能夠按照原來的順序提交結果。指令在以亂序方式執行後,其結果會被存放在 ROB 中,然後會被寫回到暫存器或者記憶體中,如果有其它指令馬上需要該結果,ROB 可以直接向所需的資料。簡而言之,ROB 的大小對於確保有足夠的亂序駐留指令以及動態分支預測的恢復,對提升指令集並行度有不可忽視的作用,例如 Apple 的 M1 處理器在某些情況下可以做到等效 600 多個條目。
我這裡使用 Travis Downs 的 rob size 工具來測試,測試的指令時單位元組 NOP,單位元組 NOP 的指令密度較高,可以減少微操作 cache 的影響。
測試結果如下:
正如大家所看到的,我們的測試結果和 Intel 官方提供的資訊一致,Golden Cove 和 Gracemont 的 ROB 大小分別是 512 和 256,Gracemont 不僅數量相差一倍,而且它表現出來的 NOP 指令測試耗時也要高出大約 29%。Zen3 的 ROB 是 256,但是它執行 NOP 指令的耗時要比 Golden Cove 更低,甚至在 ROB 溢位後依然比 Golden Cove 低,這可能和 Zen3 的微操作快取有特別的壓固最佳化有關。
接下來,讓我們再看看指令視窗的物理暫存器堆(register file)大小。
從 Cyrix 在 95 年釋出的 Cyrix M1 處理器是史上第一款具備暫存器重新命名和亂序執行能力的 x86 處理器算起,x86 處理器的亂序執行至今已經有 25 年了。
在絕大部分情況下,暫存器重新命名不一定和亂序執行是掛鉤,例如 Intel IA64 就有多達 128 個通用整數暫存器,雖然也涉及暫存器重新命名的概念,但這是編譯時的事情,在編譯時做暫存器重新命名也不見得都是好事(容易導致程式碼膨脹,降低指令快取記憶體命中率)。
對於 x86-64 這種只有 16 個指令集架構暫存器的指令集架構而言,暫存器重新命名是保障亂序執行必不可少的技術,要重新命名,自然得需要有足夠的物理暫存器才行,物理暫存器越多,可供重新命名的資源也就越多,維持亂序執行的能力就越強。
我們使用 robsize 同樣的測試程式進行了物理暫存器堆(PRF)大小的探測。這裡說明一下,我們前面的 rob 大小探測使用的是 nop (空操作)指令,不佔用任何暫存器,而接下來做的 PRF 大小推測測試,使用的是一連串的暫存器 add(加法)指令。
需要注意的是,物理暫存器堆裡同時含有亂序執行中可用於推測執行的推測暫存器數量和已提交暫存器數量,因此這種測試方式不能把直觀地把整個物理暫存器堆的大小給出來,它只能測量出可用於推測執行的暫存器數量。
從測試結果來看,Golden Cove 可用於推測執行的暫存器堆大小和 Rocket Lake/Cypress Cove 沒有什麼大的區別,都是 240 個。Gracemont 要小一些,也有 192 個,但是已經大於 Comlet Lake(第十代酷睿或者說 Skylake)的 144 個,Zen3 採用分離式整數/浮點排程器設計,它的推測可用暫存器堆大小大約是 128 個。
接下來我們看看 SIMD 向量物理暫存器堆的大小,這裡使用的是 AVX 中的 XOR 指令,在 x86 指令集中 AVX 的暫存器名稱一般都是使用 ymm 表示。
Gracemont 的 AVX ymm 暫存器隊堆大小隻有 96 個,Golden Cove 和 Zen3 都是 144 個,當暫存器堆大小溢位的時候,Golden Cove 的效能衰減程度較低,而 Gracemont 出現了非常顯著的指令吞吐衰減,以 Gracemont 數量眾多的執行埠,暫存器堆不夠用時的壓力相對明顯些。
Load / Store Buffer 大小測試
現在的處理器不僅可以亂序執行指令,還能亂序載入(Load)、儲存(Store)資料,這就涉及到 Load/Store Buffer。
x86 屬於 CISC 指令集,它的指令裡可以同時有訪存、暫存器、立即數等操作,在 SPEC CPU 2017 中,SPEC CINT2017 和 SPEC CFP2017 的 LD/ST 指令佔比就分別高達34% 和 39%,Load/Store Buffer 對 x86 的效能影響也是不容小覷的。
從測試結果來看,Gracemont 的 Load 快取大小是 80 到 82 個條目,這點是非常清晰的。
Golden Cove 的大小應該是 192 條目左右,作為對比,Golden Cove 的臺式酷睿上一代 Cypress Cove 是 128,Golden Cove 增加了 50%。
AMD 官方的說法裡 Zen3 的 Load buffer 只有 44(外加 28 個地址生成器快取,合計 72)個,但是根據軟體的測試結果,我覺得從軟體角度或者程式設計師角度,其大小更像是 114-118 條目之間(之前我說過是 116)。
從測試結果來看,Golen Cove 的 Store Buffer 大小大約是 112 個條目,Gracemont 是 48 個,Zen 3 是 64 個。
翻查之前的測試資料,Golden Cove 的上一代(Cypress Cove)是 72 個條目,這意味著 Golden Cove 在這方面的大小增加了 56%,實現亂序 Store 的機率會有一定的增強。
需說明的是,亂序 L/S 的效果與其他亂序執行指令一樣取決於多方面的因素,快取或者說佇列大小隻是其中一個較為重要的影響因素。
SPEC 2017 測試結果——4GHz 定頻
CPU 2017 是非盈利機構 SPEC(標準效能評估公司)推出的 CPU 效能評估套件,SPEC 成立於 1998 年,會員包括 Intel、AMD、IBM、DELL、聯想、華碩、技嘉等業界大公司,每隔大約 10 年就會推出一版新的 CPU 效能評估套件,CPU 2017 是該機構在 2017 年推出的,是所有處理器、電腦廠商做處理器效能評估的最重要手段之一(如果不是使用上有一定門檻,上面這句話的“之一”是可以省略的)。
SPEC CPU 的特點是由各個機構提供實際應用的原始碼,它的每一個子專案其實都是源自真實應用修改而來,其修改主要是針對可移植性和遵循的語言標準,例如 x264 的真實版本採用了大量的彙編程式碼,但是這樣的形式不利於移植到不同指令集架構上測試,因此 CPU 2017 中的 x264 採用的是純 C 語言版本。
和上一版本 CPU 2006 相比,CPU 2017 的程式碼已經全面更新,雖然依然使用 C/C++ 和 Fortran,但是相對以前的版本來說,已經變成了多語言的大混裝。Fortran 語言同時出現在浮點和整數測試集,而非像以往那樣只出現在浮點測試集。
CPU 2017 的規則更加嚴謹,speed 測試集允許使用 OpenMP 多執行緒處理,主要測試較大資料集和較大訪存壓力下的單任務多執行緒效能,而 rate 測試集則只允許單執行緒,禁止自動並行化,但是允許以多工的方式跑多個 rate 測試,目的是測試吞吐率,單個 rate 任務的訪存壓力要比 speed 小很多。
不過 speed 測試集也不是全部專案都支援多執行緒,只有浮點密集型的 fpspeed 所有專案支援多執行緒,整數密集型的 intspeed 10 個子專案中只有最後的 657.xz_s(資料壓縮)是支援多執行緒的。
這樣的規則讓以往 CPU 2006 以及更早版本中常見的編譯器自動並行化“最佳化”手段被禁止使用,減少了測試結果的混亂(測試如果使用了編譯器自動並行化後,實際上變成了編譯器比拼),提高了可比性。
備註:CPU 2017 測試需時,目前我們的舊資料只有 Zen3 4GHz 使用了 11.2 版編譯器,11.2 版編譯器在整數單執行緒、多執行緒和浮點多執行緒中有一點效能改善。其餘舊處理器執行的均為 10.2 版編譯器編譯出來的程式碼。
首先看看鎖定 4GHz 的測試結果。
從測試結果來看,單執行緒效能方面,Golden Cove 的整數效能是 Zen3 快大約 2%,比 Rocket Lake 快大約 14%,浮點方面優勢會大一些,分別是 18% 和 20%。
在多執行緒專案中,Golden Cove 的整數效能是 Zen3 快大約 1%,比 Rocket Lake 快大約 15%,浮點方面優勢會大一些,分別是 25% 和 20%。
Gracemont 的效能和 Zen+ 非常接近,單執行緒整數/浮點效能分別是 Zen+ 的 120% 和 92%,多執行緒整數/浮點分別 120% 和 102%。
大家可能注意到了,我們這裡單獨列出了全核、單純 Golden Cove、單純 Gracemont 的資料,這麼多的測試對我們來說是非常耗時的,但是從結果來看也許是有一定意義的。
我們使用的 Linux 發行版是 Ubuntu 21.10,手動安裝了 Kernel 5.15,按照理想的情況,Intel Thread Director 如果能正常運作,應該可以把過載的執行緒都扔到 p-core 或者說 Golden Cove 上執行,理論上單執行緒效能時全核和指定 Golden Cove 的資料應該是一致的。
然而事實並非如此,至少我們目前遇到的情況是 Thread Director 把幾乎所有的執行緒都優先扔到 e-core 或者說 Gracemont 上,這使得全核的資料比較一般,基本就是 Gracemont 的資料(截圖使用的是默頻時候的狀態):
fpspeed 的結果會好些,因為此時 16 個核心都在運作。然而,當我檢視核心呼叫情況的時候,情況卻是這樣的:
此時雖然是 16 個核心都在運作,但是 p-core 的佔用率只用了 90% 左右,而 e-core 則是滿載執行。
真是有點尷尬。
SPEC 2017 測試結果——默頻
接下來讓我們看看默頻的測試結果,雖然說是默頻,但是我們已經在 Linux 中啟用了 performance 高效能模式,避免省電模式下那種頻率大幅波動造成效能損失的情況。
備註:CPU 2017 測試需時,目前我們的默頻舊資料 10.2 版編譯器編譯出來的程式碼,而 ADL 使用的編譯器為最新的 11.2,11.2 版編譯器會比 10.2 有一點效能提升效果,總體大約在 1% 到 3%。
在默頻下,12900K 的 p-core 的單執行緒整數和浮點效能分別是 5800X 的 1.12 倍和 1.24 倍,在 intspeed 和 fpspeed 下分別是 1.11 倍和 1.30 倍。
默頻下由於排程器支援並未完善造成的磨洋工情況比 4GHz 更甚:
多執行緒測試的時候 p-core 只有 60% 不到的佔用。
測試總結
從微架構角度來看,Alder Lake 中的 Golden Cove 在指令解碼、執行能力上較以往的 x86 處理器都有提高,特別是指令解碼能力方面我認為達到了大幅度提升。
在同頻下,作為 e-core 的 Gracemont 的整數和浮點效能達到了 Golden Cove 的 80% 和 60%,默頻時分別為 63% 和 48%,文章中我沒有放進功耗結果,我會在一會後將 CPU2017 的 CPU 功耗結果發表在我知乎的“想法”裡,大家如果感興趣的話可以先在關注一下我(Edison Chen)。
這次測試是和 CloudLiu 一起合作的,我負責的是微架構部分基本上是在 Linux 下測試,遇到的問題主要是 Thread Director 尚未完善,導致高負載情況下執行緒依然跑到 e-core 上,但是從 CloudLiu 的 Windows 測試來看,Windows 下沒有這個問題。
相對於 Intel 今年稍早之前的 Rocket Lake 主要是對 AMD 實行防守佈局不同的是,Alder Lake 的出現意味著 Intel 開始吹響了反擊的號角,讓許多對 Rocket Lake 興趣一般但是又有升級平臺需要的消費者有了一個更好的選擇。
Alder Lake 集成了 Xe-LP 2.2 GPU,和其他 Xe GPU 一樣,具備在 Premiere Pro 2022 中硬體解碼 HEVC 4:2:2 10-bit 影片的能力,這對於 EOS R5 或者其他使用 4K120p HEVC 的影片使用者來說也是一個不錯的賣點。
從歷史來看,Intel 一直是一傢俱有深厚潛力的公司,效能出眾的 Alder Lake 再次證明了這點,來自帝國的反擊已經展開~~
本次測試平臺由華碩提供。