评估 SPEC CPU2026

# 评估 SPEC CPU2026 来源：https://chipsandcheese.com/p/evaluating-spec-cpu2026 SPEC 的 CPU 基准测试套件长期以来一直是业界标准，在阅读各类出版物时几乎不可能错过。英特尔曾用 SPEC CPU2000 展示 Pentium 4 相对于 Pentium III 的提升，三星曾用 SPEC CPU2000 和 SPEC CPU2006 的 trace 来调优他们的 Mongoose 内核，SPEC CPU2017 则构成了英特尔 Lion Cove 性能预测的一部分。现在，SPEC 已将他们的 CPU 基准测试套件更新为 SPEC CPU2026。新套件包含 52 个工作负载，高于 SPEC CPU2017 的 43 个。单个工作负载的源代码行数更多，以 KLOC（千行代码）衡量。SPEC 的目标是使其 CPU 基准测试套件现代化，同时保留 SPEC 一贯的可移植性目标。 [](https://substackcdn.com/image/fetch/$s_!1Gk3!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa43d0483-dd66-4eb3-8d92-0d2205fcba53_2000x524.png) 由于 SPEC 在 CPU 性能领域的重要性，我将仔细审视新套件的工作负载，考察它们给 CPU 带来的挑战。我关注的是硬件而非编译器对比，因此使用 GCC 14.2.0 配合 -O3 和原生架构/优化目标。我曾尝试 GCC 15.2.0，但遇到各种问题，决定坚持用 GCC 14.2.0 以节省时间。我在 Linux 上测试了以下所有系统。 SPEC CPU 分数表示相对于参考系统的加速比。每次 SPEC CPU 更新往往会更新参考系统，但并非总是更新到与最新硬件有相关性的系统。 [](https://substackcdn.com/image/fetch/$s_!WNLg!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F738726d8-dd8c-42cf-b223-177886323bd7_914x458.png) 一个 Ampere eMAG 8180 系统为 SPEC CPU2026 提供了 1.0 的参考分数。Ampere 的 eMAG 比 SPEC CPU2017 使用的 Sun Fire V490 更快，就像塞斯纳 172 可能比索普威斯骆驼快一样。两者都不是与现代客机比较的好参照。同样，Ampere eMAG 并非广泛部署的平台，甚至比它早很多年的系统也能以很大幅度超越它。我听说使用较慢系统的一部分动机是让大多数系统都能获得高分，但这本可以通过将参考分数设为更高数字（如 1000）而非 1.0 来实现。Geekbench 6 采取了更合理的方法，将 Core i7-12700 校准为 2500 的参考分数。与 Ampere 的 eMAG 不同，英特尔的 Core i7-12700 及类似 CPU 在消费系统中广泛部署，而英特尔今天在 Xeon 6 中使用相似的核心架构。 [](https://substackcdn.com/image/fetch/$s_!pzV2!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1972d0af-4402-4279-a4df-a80387b0ded0_1304x716.png) 英特尔和 AMD 最新桌面 CPU 的示例显示，在 SPEC CPU2026 的整数套件中性能相近，而 Zen 5 在浮点测试中往往领先。我不得不在一个仅达到 5.5 GHz 的 Lion Cove 核心上运行 SPEC CPU2026，因为两个能够达到 5.7 GHz 的核心在完成测试套件时遇到崩溃问题。我的样本似乎有问题，但我怀疑一个能稳定完成 5.7 GHz 测试的 Lion Cove 核心会缩小差距。 [](https://substackcdn.com/image/fetch/$s_!VNwt!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6dad33e5-8f87-48c0-b87e-92986ea45cc1_1278x1255.png) 整数套件中的单项分数显示 Zen 5 和 Lion Cove 不相上下，正如总分数所暗示的那样。绝对分数则显示出 Ampere eMAG 系统有多么落后。当前桌面核心远远超过 Ampere eMAG 中的核心，尤其是在 706.stockfish 中。即使是十多年前的 FX-8350，也可能是一个更好的参考点。它在几乎每项测试中都远超 eMAG 系统。 [](https://substackcdn.com/image/fetch/$s_!5-nN!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F260c063b-e7d1-4f0e-bf19-c4d881981dae_1307x1222.png) 浮点工作负载对老旧的 eMAG 系统来说更糟。Zen 5 在多个浮点工作负载中表现出色。部分原因是 GCC 能够生成 AVX-512 指令。我使用英特尔的 Software Development Emulator 获取每个工作负载最后一次调用的指令计数，以了解使用了哪些指令类型。一些 SPEC CPU2026 测试会多次运行同一个二进制文件以测试不同输入数据，但为了节省时间，我只分析了最后一次调用。 [](https://substackcdn.com/image/fetch/$s_!crG9!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58f72e65-fc24-460b-8bd9-989a6e91dfd7_1770x856.png) 706.stockfish、749.fotonik3d 和 765.roms 在使用 GCC 14.2.0 编译时都包含 AVX-512 代码。其他几个测试也利用了 128 位或 256 位向量。 平均 IPC（每周期指令数）粗略反映了 CPU 核心在多大程度上能发挥其执行资源。低 IPC 通常表明缓存未命中、分支预测错误，或者较少情况下是核心架构中的特定性能瓶颈。高 IPC 则表明性能更多受限于执行延迟、执行资源或核心宽度。当然，IPC 不应与实际性能混淆，实际性能还取决于时钟频率以及每条指令完成的工作量。 [](https://substackcdn.com/image/fetch/$s_!4lUh!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F20d8831d-c3fb-4290-976a-019923929f76_970x717.png) SPEC CPU2026 的整数套件在 AMD 的 Zen 5 和英特尔的 Lion Cove 上均显示出比 SPEC CPU2017 整数套件更高且更紧凑的 IPC 分布。IPC 的分布感觉接近 Geekbench 6，后者通常强调核心吞吐量，分支预测错误或最后一级缓存未命中较少。 [](https://substackcdn.com/image/fetch/$s_!fxht!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F06e66a87-37a4-4988-8a17-7545ef9c7588_968x715.png) 在更新后的套件中，Zen 5 上的浮点工作负载分布更广，而 SPEC CPU2017 的浮点测试往往集中在 2-3 IPC 附近。Lion Cove 在较旧的浮点套件中已有较广的 IPC 分布，在新的套件中仍然分布广泛。 [](https://substackcdn.com/image/fetch/$s_!BPGl!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6b62f37a-d5cb-497d-808e-065292af44c5_1836x794.png) 505.mcf 和 520.omnetpp 是 SPEC CPU2017 中低 IPC 的工作负载。两者都遭受大量缓存未命中，505.mcf 还遭受大量分支预测错误。这两个测试在 SPEC CPU2026 的整数套件中都没有等效项。MCF 已消失，而 710.omnetpp 尽管与旧测试同名，却是一个完全不同的东西。两个代码编译测试 721.gcc 和 725.llvm 成为 IPC 最低的整数测试。不过它们平均仍高于 1.5 IPC，这不算太低。作为参考，大多数 PC 游戏的平均 IPC 约为 1。 另一方面，SPEC CPU2026 的整数套件包含大量高 IPC 的工作负载。超过一半的平均 IPC 接近 3 甚至更高。750.sealcrypto 在 Zen 5 和 Lion Cove 上均达到所有整数工作负载中最高的 IPC。在 Skymont E-Core 上它也是高 IPC 工作负载，只是稍低一些。 [](https://substackcdn.com/image/fetch/$s_!jzWD!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd8fd8c87-24cf-454e-ae8c-71852e247c38_1986x708.png) SPEC 的浮点工作负载往往侧重于核心吞吐量，SPEC CPU2026 也是如此。许多工作负载的 IPC 高于 2，我认为这属于中等至中高等 IPC 范围。749.fotonik3d 和 765.roms 与它们在 SPEC CPU2017 中的对应项扮演相同角色，并继续通过经常在最后一级缓存中未命中来考验 DRAM 性能。在高 IPC 端，538.imagick 已消失且没有直接替代品。有几个 SPEC CPU2026 浮点工作负载的平均 IPC 远高于 3，但没有一个能达到像 538.imagick 那样天文数字般的高度。 自上而下分析将未充分利用的核心宽度归因于不同原因，并提供了核心吞吐量可能在哪里损失的高层概览。它在重命名/分配阶段工作，这通常是 CPU 流水线中最窄的部分，所有指令都必须通过。在该阶段，每个流水线槽位分类如下： - **退役中**：槽位被最终退役的微操作使用，意味着其结果在通过所有检查后在架构上可见。退役的微操作代表有用工作。 - **后端受限**：前端有可用微操作，但由于所需的乱序跟踪资源不可用而无法发送到后端。这可能意味着重排序缓冲区、寄存器文件或内存排序队列在需要时没有空闲条目。 - **前端受限**：前端未能提供足够的微操作来填满所有重命名器槽位。 - **错误推测**：微操作通过了槽位但未退役。这代表浪费的工作，例如来自分支预测错误。 [](https://substackcdn.com/image/fetch/$s_!VECS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3ab13ac6-1c08-4d56-8a62-ae60106d43c4_1193x1066.png) 与 SPEC CPU2017 的整数套件相比，退役槽位整体上升，考虑到上面看到的更高 IPC 数据，这是意料之中的。723.llvm 和 721.gcc 主要受限于前端延迟，即前端未能向重命名器提供任何微操作的周期。723.llvm 和 721.gcc 都是分支密集的工作负载，偶尔会遇到预测错误，这会打断前端跟踪指令流并顺畅传递微操作的能力。另一端，750.sealcrypto 几乎没有分支。Lion Cove 和 Zen 5 都能无阻碍地通过它，因为它们的后端也没有太多减速因素。 [](https://substackcdn.com/image/fetch/$s_!egaQ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9260e900-7949-40e3-b404-f9dad0a2cac8_1948x940.png) SPEC CPU2017 的浮点工作负载往往更侧重于核心吞吐量，SPEC CPU2026 中也是如此。分支通常稀少且可预测，使得 Lion Cove 和 Zen 5 的前端能以高效率运行。 [](https://substackcdn.com/image/fetch/$s_!qL6h!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F721dd629-8c7f-4270-92c3-a238c94606b2_1188x1206.png) 在 Lion Cove 和 Zen 5 上，Fotonik3d 和 roms 都严重受限于后端内存。大多数其他测试受限于核心，但也有例外。Lion Cove 和 Zen 5 在类似方面受到挑战，但 709.cactus 例外。在该测试中，Zen 5 受限于前端带宽，意味着前端传递了一些微操作，但不足以填满所有八个重命名器槽位。 [](https://substackcdn.com/image/fetch/$s_!HjKb!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ffdf06d38-7926-4914-a929-201783cd8405_1946x939.png) Lion Cove 的前端在 709.cactus 中表现出色，但核心遇到后端限制，总体而言英特尔无法领先 AMD。 数十年来，分支预测一直是设计高性能 CPU 的关键挑战。SPEC CPU2017 的整数测试通常对分支预测具有挑战性，即使对于拥有复杂分支预测器的现代核心也是如此。505.mcf、541.leela 和 557.xz 在 AMD 的 Zen 5 上都遭受大量预测错误。这些测试会奖励那些具有更好分支预测、更快分支解析以及能够将预测错误惩罚隐藏在其它工作之后的能力的 CPU。 [](https://substackcdn.com/image/fetch/$s_!uPGZ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8149865a-7f7d-4ac8-bc4b-37a0fbe09f3e_1554x765.png) 这里使用每千条指令的预测错误数 (MPKI)，因为比起分支预测准确率，它更能刻画工作负载受预测错误影响的程度。一个工作负载的分支预测准确率可能很差，但如果指令流中分支很少，影响可能不大。 SPEC CPU2026 的整数套件对分支预测的强调程度较低。721.llvm 仍然是一个中等挑战，但每条指令的预测错误数少于 557.xz，更不用说 505.mcf 和 541.leela 了。分支预测方面的难度降低也促进了更高的平均 IPC。 [](https://substackcdn.com/image/fetch/$s_!EDp0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F729b487d-64f5-4e88-9eea-f7f8b915bc84_1496x1177.png) SPEC CPU2017 中的浮点工作负载对分支预测器的挑战通常较小，但并非总是如此。526.blender 确实因错误推测损失了吞吐量，但 SPEC CPU2017 的浮点测试在分支预测难度上远未达到 557.xz、505.mcf 或 541.leela 的水平。 [](https://substackcdn.com/image/fetch/$s_!GzTW!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22889eaf-300b-465c-bd24-404321f2101c_1499x790.png) SPEC CPU2026 在这方面有所变化，731.astcenc 成为整数和浮点套件中最大的单一分支预测挑战。它仍然没有 SPEC CPU2017 整数套件中 505.mcf 那样大的挑战，但应该足以代表一个具有不可预测控制流的工作负载。 [](https://substackcdn.com/image/fetch/$s_!rIFx!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F022e54df-4e98-4765-b9ac-b8c7dd947381_1406x1216.png) 良好的缓存不仅对数据重要，对指令也很重要。AMD 近期的核心倾向于优化小指令足迹，并力求在高度优化的微操作缓存中捕获大部分指令流。SPEC CPU2026 的整数套件比 SPEC CPU2017 更挑战这一方法。多个工作负载的微操作缓存覆盖率低于 80%，因此 SPEC 转向源代码行数更多的工作负载有时与更差的代码局部性相关。不过，Zen 5 仍然能够主要从微操作缓存运行代码，解码器使用不多。 [](https://substackcdn.com/image/fetch/$s_!ROfa!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F73d91ce2-533a-45b3-81d4-0c318c22b3c6_1531x1376.png) 在缓存层次结构的更深处，许多微操作缓存覆盖率低于 90% 的测试也出现了显著的 L1 指令缓存未命中。自 Zen 2 以来，AMD 一直坚持使用 32 KB 的 L1 指令缓存，这并不能在微操作缓存之上提供太多额外覆盖。在几乎所有测试中，1 MB 的 L2 缓存足以捕获绝大多数 L1 指令缓存未命中。只有两个代码编译工作负载出现了明显的 L2 未命中的代码获取，这可能有助于解释它们较低的 IPC。 [](https://substackcdn.com/image/fetch/$s_!Bs7w!,f