英特尔高性能CPU：Lion Cove深入解读

公众号记得加星标⭐️，第一时间看推送不会错过。

来源：内容编译自chipsandcheese。

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

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

今天是《半导体行业观察》为您分享的第4089期内容，欢迎关注。

加星标⭐️第一时间看推送，小号防走丢

求推荐