英特爾高性能CPU：Lion Cove深入解讀

Lion Cove 是英特爾最新的高性能 CPU 架構。與其前代 Raptor Cove 相比，英特爾最新的核心可以支持更多指令周期，重新組織了執行引擎，並在數據緩存層級結構中增加了一個級別。此外，核心流水線的幾乎所有部分都進行了調整，改進之處還有很多。Lion Cove 在 SPEC CPU2017 標準基準測試套件中表現出色，尤其是在更高的 IPC 子測試中取得了顯著的提升。

在 Arrow Lake 桌面平臺上，Lion Cove 的性能通常可以與 AMD 的 Zen 5 架構相媲美，並且在功耗更低的情況下，整體性能領先於英特爾上一代 Raptor Cove。但很多遊戲玩家更看重遊戲性能，而遊戲對生產力工作負載的需求也有所不同。

在這里，我將運行幾款遊戲並收集性能監控數據。我使用的是酷睿 Ultra 9 285K 處理器，搭配 DDR5-6000 28-36-36-96 內存，這是我目前能用到的最快內存。BIOS 中已關閉 E 核，因為設置與 P 核關聯會導致《使命召喚》遊戲嚴重卡頓。在《賽博朋克 2077》中，我使用內置基準測試，分辨率為 1080P，設置中等，並關閉了升級功能。在《Palworld》中，我待在基地附近，因為周圍實體越多，CPU 負載就越高。

遊戲工作負載通常處於 IPC 範圍的低端。Lion Cove 每周期可以支持 8 個微操作，這大致相當於每周期 8 條指令，因為大多數指令都映射到單個微操作。它在 SPEC CPU2017 的多項測試中都取得了非常高的 IPC 數據，其中一些甚至超過了 4 IPC。然而，遊戲的表現遠不及 IPC 水平，而且 IPC 測試結果較低，性能受到前端和后端延迟的限制。

自上而下的視圖

自上而下的分析可以描述應用程序對 CPU 核心帶寬的利用情況，並解釋流水線槽位利用不足的原因。分析通常在重命名/分配階段進行，因為該階段通常是核心流水線中最窄的階段，這意味着該階段的吞吐量損失無法在之后恢復。簡要分析一下原因：

錯誤推測：插槽已利用，但核心卻走錯了路徑。這通常是由於分支預測錯誤造成的。

前端延迟：前端沒有向該周期的重命名器提供任何微操作

前端帶寬：前端提供了一些微操作，但不足以填滿所有重命名器插槽（Lion Cove 上有八個）

核心受限：后端無法從前端接受更多微操作，並且阻止退出的指令不是內存負載

后端內存綁定：與上文相同，但阻止指令退出的操作屬於內存加載。英特爾僅將該事件描述為「TOPDOWN.MEMORY_BOUND_SLOTS」（事件 0xA4，單元掩碼 0x10），但 AMD 和其他公司明確使用內存加載阻止退出作為其相應指標的標準。英特爾很可能也採取了同樣的措施。

退出：重命名器槽已被利用，相應的微操作最終被退出（有用的工作）

核心寬度利用率低，正如上面的 IPC 數據所暗示的那樣。后端內存延迟導致多個流水線槽丟失，儘管指令執行延迟（核心綁定）和前端延迟仍有改進空間。預測錯誤和前端帶寬並非主要問題。

后端內存訪問

Lion Cove 採用四級數據緩存設置，其中 L1 數據緩存分為兩級。爲了簡單起見，我將其分別稱為 L1 和 L1.5，因為 L1 的第二級緩存在容量和性能上介於第一級緩存和 3 MB 的 L2 緩存之間。

Lion Cove 的 L1.5 能夠彌補 L1 內存中相當一部分的命中率問題，儘管其命中率絕對值並不高。它給人一種 RDNA 128 KB L1 的感覺，因為它可以減輕 L2 的負載，但命中率通常比較平庸。在《使命召喚》、《Palworld》和《賽博朋克 2077》中，L2 的命中率分別為 49.88%、71.87% 和 50.98%。在這三款遊戲中，L1.5 和 L2 的累計命中率分別為 75.54%、85.05% 和 85.83%。英特爾使用更大的 L2 來阻止 L3 的流量的策略在一定程度上是有效的，因為大多數 L1 命中問題都可以在不離開核心的情況下得到處理。

然而，訪問 L3 和 DRAM 的內存訪問成本非常高昂。Lion Cove 可以讓你瞭解內存層次結構中每個級別限制性能的頻率。具體來説，性能監控事件會統計沒有準備好執行微操作、特定緩存級別的加載處於掛起狀態以及沒有加載錯過該緩存級別的周期數。例如，如果內核正在等待來自 L3 的數據，而沒有同時等待來自 DRAM 的數據，並且內核中排隊的所有待處理指令都被阻止等待數據，則該周期將被限制在 L3 範圍內。執行階段的停頓並不意味着性能受到影響，因為內核的執行端口比重命名器插槽多。執行階段可以在停頓幾個周期后繼續運行而不會損失平均吞吐量。因此，這衡量的是內核必須應對的難度，而不是它是否能夠應對。

英特爾的性能事件不區分 L1 和 L1.5，因此上圖中兩者都被計為「L1 受限」。L1.5 似乎將足夠多的訪問從 L2 移出，從而最大限度地降低了 L2 延迟的影響。不過，除了 L2 之外，L3 和 DRAM 的性能也產生了顯著的影響。L2 未命中率可能絕對罕見，但考慮到 L3 或 DRAM 訪問的高成本，這種概率並不算太低。

Lion Cove 和 Arrow Lake 平臺可以監控內存層級結構中各個節點的隊列佔用率。將佔用率除以請求數，即可得出周期內的平均延迟，從而瞭解核心在實際中需要應對的延迟量。

計算 DCACHE_PENDING 子事件 0 的發生次數（上升沿）。實現發送每個端口的二進制 inc-bit，佔用率增加*（在 FB 分配或提升時）。

英特爾對 L1D_MISS.LOAD 事件的描述，沒有表明它屬於 L1 的哪個級別。

這些性能監控事件可能會令人困惑。當加載未命中 48 KB L1D 時，L1D_MISS.LOAD 事件（事件 0x49，單元掩碼 1）會遞增。然而，相應的 L1D_PENDING.LOAD 事件（事件 0x48，單元掩碼 1）僅計算未命中 192 KB L1.5 的加載。結合使用這兩個事件會將 L1.5 命中視為零延迟。它確實準確地計算了 L2 及更高級別的延迟，儘管這只是從 L1.5 和 L2 之間的隊列角度來看的。

測量仲裁隊列 (ARB) 的延迟可能會以另一種方式令人困惑。ARB 以 CPU 塊的非核心時鍾頻率（即 3.8 GHz）運行。這遠低於 5.7 GHz 的最高 CPU 核心時鍾頻率，因此 ARB 的延迟周期會比 CPU 核心的要少。因此，我添加了另一組條形圖，其中 ARB 后延迟乘以 5.7/3.8，以近似 CPU 核心周期的延迟。

另一種控制延迟的方法是乘以周期時間，以估算實際延迟。Arrow Lake 的時鍾並非靜態的，因此存在額外的誤差範圍。但這樣做確實表明，超過 ARB 的延迟仍然得到良好控制，因此 DRAM 帶寬並非問題。如果遊戲接近 DRAM 帶寬極限，隨着請求開始在 ARB 隊列以及芯片互連的后續點上堆積，延迟將會大幅增加。

前端

大部分操作發生在后端，但 Lion Cove 在前端也會損失一些吞吐量。指令端訪問往往比數據端訪問更可預測，因為指令在覈心到達分支之前是按順序執行的。這意味着準確的分支預測可以讓核心隱藏前端延迟。

Lion Cove 的分支預測器在這三款遊戲中都擁有出色的準確性。然而，預測錯誤仍然是一個問題。正如偶爾的 L3 或 DRAM 訪問可能會因為成本高昂而帶來問題一樣，從分支預測錯誤中恢復也同樣困難。由於預測錯誤會破壞分支預測器的提前運行能力，它會使核心面臨指令端緩存延迟。從 L2 或更高級別獲取正確的分支目標可能會增加數十個周期的預測錯誤恢復時間。理想情況下，核心應該將應用程序的大部分代碼佔用空間包含在最快的指令緩存級別中，以最大限度地減少這種損失。

Lion Cove 的前端可以從四個來源獲取微操作。循環緩衝區（又稱循環流檢測器 (LSD)）和微碼序列器起着次要作用。大多數微操作來自微操作緩存（又稱解碼流緩衝區 (DSB)）。即使操作緩存提供了大多數微操作，它也不足以作為核心的主要指令緩存。Lion Cove 擁有一個 64 KB 的指令緩存，該緩存繼承自 Redwood Cove。英特爾不再記錄允許直接計算 L1i 命中率的事件。但是，Alder Lake 之前的舊事件似乎仍然有效。微操作緩存命中被計為通過微基準測試獲得的指令緩存命中。因此，下圖表示在不進入 L2 的情況下滿足指令獲取的頻率。

64 KB 指令緩存發揮了作用，阻止了絕大多數指令讀取到達 L2。L2 的代碼命中率較低，這可能是因為 L1i 未命中的訪問首先具有更差的局部性。指令還必須與數據爭奪 L2 的容量。L2 代碼未命中的情況並不常見，但由於延迟急劇增加，它可能會像數據端一樣造成問題。

在這三款遊戲中，賽博朋克 2077 的內置基準測試代碼局部性更佳，而 Palworld 則表現最差。這反映在覈心的平均指令端延迟上。運行 Palworld 時，Lion Cove 需要更長時間才能從流水線重引導中恢復，這主要源於分支預測錯誤。這里的恢復時間指的是重命名器從正確路徑發出第一個微操作之前所經過的周期數。

核外代碼讀取延迟可以像需求數據讀取一樣進行跟蹤。延迟低於數據端，這表明 L3 的代碼命中率更高。然而，隱藏數百個周期的延迟對於前端來説仍然是一項艱鉅的任務，就像對於后端一樣。同樣，Lion Cove 強大的 L2 承擔了大量繁重的工作。

性能計數器還能洞察其他延迟。A 遊戲從重命名器（分配器）恢復已知良好狀態的檢查點[1]開始，這需要 3-4 個周期，並且正如預期的那樣，在三款遊戲中都沒有變化。Lion Cove 還可以指示指令獲取階段停頓的頻率。設置 edge/cmask 位可以指示每次停頓的持續時間。然而，由於前端具有深度隊列，可能會隱藏 L1i 未命中延迟，因此很難確定 L1i 未命中對性能的影響。此外，指令獲取停頓可能與后端資源停頓重疊。

雖然流水線重引導似乎是造成前端吞吐量損失的主要原因，但其他原因也可能導致損失。分支預測器內的結構可能會相互覆蓋，例如，較慢的 BTB 級別會覆蓋較快的 BTB 級別（BPClear）。較大的分支佔用空間可能會超出分支預測器的跟蹤能力，從而導致英特爾術語中的 BAClear。這時，前端會發現一個未被預測器跟蹤的分支，並且必須重定向來自后續階段的指令提取。來自這兩個來源的流水線氣泡影響較小，因此 Lion Cove 的巨型 12K 入口 BTB 表現良好。

其他觀察

在遊戲等受延迟限制的工作負載中，退出階段的運行方式如同「盛宴或饑荒」一樣。大多數時候它什麼也做不了。這可能是因為長延迟指令阻礙了退出，或者由於代價高昂的錯誤預測導致ROB空了。當退出階段暢通無阻時，吞吐量就像一條浴缸曲線。通常情況下，它會緩慢地向前移動，大多數退出槽都處於空閒狀態。在中高吞吐量下，退出階段幾乎不會花費任何周期進行退出。

很可能，在覈心受限的場景中，當一個短延迟操作完成並解除對一些其他即將完成的微操作的阻塞時，退出操作會緩慢地向前爬行，或者在一條長延迟指令完成並解除對許多已經完成的指令的退出阻塞后，退出操作會突然向前爆發。

Lion Cove 每個周期最多可退出 12 條微操作。一旦開始使用其全部退出寬度，核心平均會執行 28 條微操作，之后纔會再次被阻塞。

最后的話

與Zen 4相比，Lion Cove 的后端內存延迟問題更加嚴重，但前端延迟問題則小得多。部分原因在於 Zen 4 擁有更強大的數據端內存子系統。我之前測試過的 AMD Ryzen 9 7950X3D 在第一個芯片上擁有 96 MB 的三級緩存，其三級緩存延迟低於英特爾 Arrow Lake 平臺上的 Lion Cove。除了三級緩存之外，即使使用速度較慢的 DDR5-5600 36-36-36-89 內存，AMD 也能實現更佳的加載到使用延迟。英特爾在轉向 chiplet 架構后，其互連變得更加複雜，顯然還有一些工作要做。

Lion Cove 也有很多亮點，因為它的核心前端非常強大。與 Zen 4 相比，更大的 BTB 和更大的指令緩存似乎能夠很好地避免代碼提取到較慢的緩存中。Lion Cove 強大的 L2 緩存也功不可沒。它並非完美無缺，因為偶爾出現的指令端 L2 未命中會導致平均延迟在數百個周期的範圍內。但英特爾對前端的改進確實帶來了回報。

儘管英特爾和 AMD 的相對優勢各有不同，但一個不變的因素是遊戲難度高，IPC 工作負載低。它們的數據端佔用空間大，訪問局部性差。指令端訪問也很困難，但程度不如 AMD，因為現代分支預測器大多能跟上。這兩個因素加在一起意味着許多流水線槽未被使用。構建更寬的內核幾乎沒有什麼好處，因為執行指令不是問題。相反，挑戰在於處理內核等待數據或指令從低級緩存或 DRAM 到達時的長時間停頓。英特爾新的 L1.5 可能影響也有限。它確實將一些已經很快的 L2 命中轉換為更快的訪問，但它對內核等待來自 L3 或 DRAM 的數據時的長時間停頓無濟於事。

將遊戲與 SPEC CPU2017 進行比較也強調了遊戲並非唯一的工作負載。更寬的內核和更快的上級緩存在很多 SPEC CPU2017 測試中都能帶來回報，尤其是在 IPC 非常高的測試中。相反，專注於提升 DRAM 性能或增加末級緩存容量，對於已經能夠容納緩存的工作負載而言，收益微乎其微。針對不同工作負載的優化策略經常相互衝突，因為工程師必須決定如何在有限的功耗和麪積預算內進行分配。他們也只有有限的時間來找到最佳的權衡方案。英特爾、AMD 和其他公司將繼續調整其 CPU 設計以滿足預期的工作負載，拭目以待他們的未來發展。

參考鏈接

https://chipsandcheese.com/p/intels-lion-cove-p-core-and-gaming