英特尔的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，中等画质，关闭缩放功能。在《幻兽帕鲁》中，在基地附近活动，因为周围实体越多，CPU 负载往往越高。

游戏工作负载通常处于 IPC 范围的低端。Lion Cove 每周期可执行 8 个微操作，这大致相当于每周期 8 条指令，因为大多数指令都对应一个微操作。在多项 SPEC CPU2017 测试中，它的 IPC 数值非常高，有些甚至远超 4 IPC。然而，游戏的 IPC 远未达到这个水平，其表现更接近那些 IPC 较低的测试 —— 这些测试的性能受限于前端和后端延迟。

自上而下分析

自上而下分析用于描述应用程序对 CPU 核心宽度的利用情况，并解释流水线槽位未被充分利用的原因。这通常在重命名 / 分配阶段进行，因为这一阶段往往是核心流水线中最窄的阶段，意味着在该阶段损失的吞吐量无法在后续阶段弥补。简要分析原因如下：

• 错误推测：槽位被利用，但核心走了错误的路径。这通常是由于分支预测错误导致的。
• 前端延迟：该周期内前端未向重命名器输送任何微操作。
• 前端带宽：前端向重命名器输送了一些微操作，但不足以填满所有重命名器槽位（Lion Cove 有 8 个）。
• 核心受限：后端无法从前端接收更多微操作，且阻碍指令提交的并非内存加载操作。
• 后端内存受限：与上述情况类似，但阻碍指令提交的是内存加载操作。英特尔仅将该事件描述为 “TOPDOWN.MEMORY_BOUND_SLOTS”（事件 0xA4，单元掩码 0x10），但 AMD 等厂商在相应指标中明确采用内存加载阻碍提交这一判定标准。英特尔很可能也是如此。
• 提交中：重命名器槽位被利用，且相应的微操作最终完成提交（有效工作）。

正如上述 IPC 数据所示，核心宽度的利用率较低。后端内存延迟是导致流水线槽位损失的主要原因，不过在指令执行延迟（核心受限）和前端延迟方面也有改进空间。错误推测和前端带宽并非主要问题。

后端内存访问

Lion Cove 采用 4 级数据缓存设置，其中 L1 数据缓存分为两级。为简便起见，我将它们称为 L1 和 L1.5，因为 L1 的第二级在容量和性能上介于第一级和 3MB 的 L2 缓存之间。

Lion Cove 的 L1.5 缓存承接了相当一部分 L1 缓存未命中的访问，尽管其命中率绝对值并不高。这让人联想到 RDNA 的 128KB L1 缓存 —— 它减轻了 L2 的部分负担，但命中率往往平平。在《使命召唤》《幻兽帕鲁》和《赛博朋克 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 之后，L3 和 DRAM 的性能影响显著。从绝对数量上看，L2 未命中可能并不常见，但考虑到访问 L3 或 DRAM 的高昂代价，其发生频率仍偏高。

Lion Cove 和 Arrow Lake 平台可以监控内存层级中各个节点的队列占用情况。将占用量除以请求数，可得到以周期为单位的平均延迟，从而了解核心实际需要应对的延迟大小。

DCACHE_PENDING 子事件 0 的计数次数（上升沿）。当占用率增加时，Impl. 发送每个端口的二进制增量位 *（在 FB 分配或提升时）。
—— 英特尔对 L1D_MISS.LOAD 事件的描述，该描述未明确说明统计的是哪一级 L1 缓存。

这些性能监控事件可能令人困惑。L1D_MISS.LOAD 事件（事件 0x49，单元掩码 1）在加载操作未命中 48KB 的 L1D 时递增。然而，相应的 L1D_PENDING.LOAD 事件（事件 0x48，单元掩码 1）仅统计未命中 192KB L1.5 的加载操作。将这两个事件结合使用时，会将 L1.5 命中视为零延迟。不过，从 L1.5 和 L2 之间的队列角度来看，它确实准确地统计了到 L2 及更高级别的延迟。

测量仲裁队列（ARB）的延迟也存在另一种困惑。ARB 以 CPU tile 的非核心时钟运行，即 3.8GHz。这远低于 5.7GHz 的最大 CPU 核心时钟，因此 ARB 记录的延迟周期数少于 CPU 核心感知的周期数。因此，我添加了另一组柱状图，将 ARB 后的延迟乘以 5.7/3.8，以近似 CPU 核心周期中的延迟。

另一种了解延迟的方法是乘以周期时间以近似实际延迟。Arrow Lake 的时钟频率并非固定，因此存在额外的误差 margin。但这确实表明，ARB 之后的延迟得到了很好的控制，因此 DRAM 带宽并非问题所在。如果游戏接近 DRAM 带宽限制，那么随着请求在 ARB 队列及芯片互连的后续节点堆积，延迟会大幅增加。

前端

后端的活动较多，但 Lion Cove 的前端也损失了一些吞吐量。指令侧访问往往比数据侧访问更具可预测性，因为在遇到分支之前，指令是按顺序执行的。这意味着准确的分支预测可以帮助核心隐藏前端延迟。

Lion Cove 的分支预测器在这三款游戏中都具有极高的准确率。然而，预测错误仍可能成为问题。正如偶尔的 L3 或 DRAM 访问因其高昂代价而影响显著一样，从分支预测错误中恢复也会造成损失。因为预测错误会破坏分支预测器的超前执行能力，可能导致核心暴露在指令侧缓存延迟中。从 L2 或更高级别缓存中获取正确的分支目标，可能会使恢复时间增加数十个周期。理想情况下，核心应将应用程序的大部分代码足迹保存在最快的指令缓存中，以最大限度地减少这种损失。

Lion Cove 的前端可以从四个来源获取微操作。循环缓冲区（或循环流检测器 LSD）和微码定序器的作用较小。大多数微操作来自微操作缓存（或解码流缓冲区 DSB）。尽管操作缓存提供了大部分微操作，但它的容量不足以作为核心的主要指令缓存。Lion Cove 配备了 64KB 的指令缓存，这是从 Redwood Cove 继承而来的。英特尔不再提供可直接计算 L1i 命中率的事件文档。然而，Alder Lake 之前的旧事件似乎仍然可用。通过微基准测试可知，微操作缓存命中被计为指令缓存命中。因此，以下数据表明了无需访问 L2 即可满足指令获取的频率。

64KB 的指令缓存表现良好，绝大多数指令获取无需访问 L2。L2 的代码命中率较低，这可能是因为未命中 L1i 的访问本身就具有较差的局部性。此外，指令还需与数据竞争 L2 的容量。虽然 L2 代码未命中并不常见，但如同数据侧一样，其延迟的大幅增加可能造成问题。

在这三款游戏中，《赛博朋克 2077》的内置基准测试具有更好的代码局部性，而《幻兽帕鲁》的表现最差。这反映在核心感知到的平均指令侧延迟上。运行《幻兽帕鲁》时，Lion Cove 从流水线重定向中恢复所需的时间更长，这主要源于分支预测错误。此处的恢复时间指从重命名器发出正确路径的第一个微操作所需的周期数。

可以通过与跟踪请求数据读取相同的方式来跟踪核外代码读取延迟。指令侧的延迟低于数据侧，这表明 L3 中的代码命中率更高。然而，对于前端而言，隐藏数百个周期的延迟仍然极具挑战性，就像后端一样。同样，Lion Cove 的大容量 L2 缓存发挥了重要作用。

性能计数器还能揭示其他延迟。重命名器（分配器）首先恢复具有已知良好状态的检查点 [1]，这需要 3-4 个周期，且在三款游戏中保持一致。Lion Cove 还能显示指令获取阶段的停顿频率。设置边缘 / 掩码位可以指示每次停顿的持续时间。然而，很难确定 L1i 未命中对性能的影响，因为前端有较深的队列，可以隐藏 L1i 未命中延迟。此外，指令获取停顿可能与后端资源停顿重叠。

虽然流水线重定向似乎是前端吞吐量损失的主要原因，但其他因素也可能造成影响。例如，分支预测器内部的结构可能相互覆盖，如较慢的 BTB 级别覆盖较快的级别（BPClear）。较大的分支足迹可能超出分支预测器的跟踪能力，在英特尔术语中称为 BAClear。此时，前端会发现未被预测器跟踪的分支，必须从后续阶段重定向指令获取。这两种情况造成的流水线空泡影响较小，因此 Lion Cove 的 12K 项大型 BTB 表现良好。

其他观察

在游戏这类受延迟限制的工作负载中，提交阶段的工作状态极不稳定。大多数时间里，它无法进行任何操作。这可能是因为长延迟指令阻碍了提交，或者由于严重的预测错误导致重排序缓冲区（ROB）为空。当提交阶段解除阻塞时，吞吐量呈现浴盆曲线特征。通常，它会缓慢推进，大多数提交槽位处于空闲状态。提交阶段很少以中高吞吐量进行提交。

可能的情况是，在核心受限场景中，当短延迟操作完成并解除对其他即将完成的微操作的阻塞时，提交阶段会缓慢推进；或者，在长延迟指令完成并解除对大量已完成指令的提交阻塞后，提交阶段会快速推进。

Lion Cove 每周期最多可提交 12 个微操作。一旦开始充分利用其提交宽度，核心平均会在再次被阻塞前处理 28 个微操作。

结语

与 Zen 4 相比，Lion Cove 受后端内存延迟的影响更大，但受前端延迟的影响小得多。部分原因在于 Zen 4 更强的数据侧内存子系统。我之前测试的 AMD 锐龙 9 7950X3D 在第一颗芯片上拥有 96MB 的 L3 缓存，且在英特尔 Arrow Lake 平台中，其 L3 延迟低于 Lion Cove。在 L3 之外，即使使用速度较慢的 DDR5-5600 36-36-36-89 内存，AMD 也实现了更低的加载到使用延迟。英特尔在转向小芯片架构后，互连变得更加复杂，显然还有改进空间。

Lion Cove 在很多方面也做得很好，因为其核心前端性能相当强劲。与 Zen 4 相比，更大的 BTB 和更大的指令缓存似乎有效地减少了对速度较慢的缓存的代码读取。Lion Cove 的大容量 L2 缓存也功不可没。当然，它并非完美无缺，因为偶尔的指令侧 L2 未命中平均会导致数百个周期的延迟。但英特尔在前端的改进确实取得了成效。

尽管英特尔和 AMD 各有优势，但有一个不变的事实：游戏是难度大、IPC 低的工作负载。它们的数据侧足迹大，访问局部性差。指令侧访问也颇具挑战性，尽管现代分支预测器基本能够应对。这两个因素共同导致了许多流水线槽位未被利用。构建更宽的核心几乎没有益处，因为处理指令并非问题所在。相反，挑战在于处理核心等待低级别缓存或 DRAM 中的数据或指令时的长时间停顿。英特尔新的 L1.5 的影响可能也有限。它确实将一些本已较快的 L2 命中转化为更快的访问，但无法缓解核心等待 L3 或 DRAM 数据时的长时间停顿。

将游戏与 SPEC CPU2017 进行比较也凸显了游戏并非唯一的工作负载。在许多 SPEC CPU2017 测试中，尤其是那些具有极高 IPC 的测试，更宽的核心和更快的高级别缓存能带来显著收益。相反，对于那些已能放入缓存的工作负载，改善 DRAM 性能或增加末级缓存容量的收益微乎其微。不同工作负载的优化策略往往相互冲突，因为工程师必须决定如何分配有限的功耗和面积预算。他们也需要在有限的时间内确定最佳权衡。英特尔、AMD 和其他厂商将继续调整其 CPU 设计，以适应预期的工作负载，看看它们的发展方向将会很有趣。