NVIDIA Olympus 核微架构实测：以每时钟性能冲击服务器单线程上限

传统上，服务器芯片的单线程性能低于同时代的客户端芯片。更高的核心数意味着每核心可分配的功耗更低，而连接众多核心所需的复杂互连往往也会带来更高的延迟。然而，这一趋势一直在收窄。AMD 近几代服务器芯片一直在推高频率。NVIDIA 的 Olympus 是推动服务器单线程性能向前发展的又一激进举措，但它从不同角度切入这一问题，更侧重于每时钟性能。

为实现这一目标，Olympus 采用了与 Arm Cortex X925 类似的方法。增大核心结构往往会遇到收益递减，因此 Olympus 与 Arm 的做法不同，采用了同步多线程（SMT）实现。其结果是一颗怪兽级核心，在服务器领域不容小觑，而且其性能非常接近桌面级。概述

Olympus 是一个 10 宽乱序核心，其乱序结构在某些方面大得几乎滑稽。它运行在适中的 3.3 GHz 时钟频率上，这在如今即便按服务器标准也不算高，因此 Olympus 需要非常强的每周期性能才能达到 NVIDIA 的性能目标。

从高层来看，Olympus 的整体布局与 Arm Cortex X925 有很多共同之处。两个核心都采用半分布式调度器，执行单元布局也相似。两者都旨在实现高性能，而无需达到 AMD 和 Intel 核心那样的时钟速度。然而，Olympus 通过相比 X925 增大乱序结构规模，将这一目标推得更远。NVIDIA 的核心在若干方面也有所不同，例如在浮点调度器前设有一个非调度队列。分支预测

一个具有深度重排序能力的宽核心会因分支误预测而损失惨重，因此 Olympus 需要强大的分支预测器。在针对不同模式长度、不同数量且取/不取的分支进行的测试中，Olympus 仅略逊于 Arm 的 X925。X925 的方向预测器在有几个分支参与时可跟踪约 16-24K 全局历史模式，在 512 个分支时可跟踪超过 64K 个模式。Olympus 在有几个分支时可达到约 5-6K 个模式，在 512 个分支时可达到 48K 个。

在 SPEC CPU2026 中，预测准确率与 Intel 和 AMD 最佳核心不相上下。总体而言，Olympus 略落后于 AMD 的 Zen 5，略领先于 Lion Cove。各核心在不同工作负载上各有胜负，凸显了优化分支预测器以应对广泛程序行为的难度。

SPEC CPU2026 的浮点套件通常对分支预测器较为友好，但仍包含几个带有轻微分支预测挑战的工作负载。Olympus 在浮点套件中领先于 Intel 和 AMD，主要归功于在 731.astcenc 中的大幅领先。

分支预测速度对于为宽而高吞吐的设计提供指令也至关重要，因为取分支在代码中相当常见。与 AMD 的 Zen 5 一样，Olympus 可以在较大的分支足迹范围内每周期执行两个取分支。与 Zen 5 和 Cortex X925 不同，Olympus 每周期执行两个取分支的能力与指令足迹而非分支数量挂钩，这可能意味着它与指令缓存相关。超过 48 KB 的指令足迹会破坏每周期两个分支的能力。对于更大的指令或分支足迹，Olympus 有一个 16K 条目的 BTB，延迟为 4 个周期。

NVIDIA 对分支目标缓存结构进行了分区，以便核心运行两个线程时每个线程获得约一半的可用容量。两个线程不能共享目标，即使它们属于同一进程并因此共享地址空间。从最快的 BTB 层级来看，持续取分支吞吐量仍为每周期两个分支。在服务两个线程时，从每个线程的角度看，16K 条目的 L2 BTB 可以每五个周期提供一个取分支目标，或者从核心的角度看大约每 2-3 个周期提供一个。

SMT2 = 同一微基准测试进程启动两个线程。所示数据是从线程角度得出的

NVIDIA 和 AMD 都使用提前索引来提高分支预测器吞吐量，这意味着一次查找为接下来两个分支而非单个分支提供预测。NVIDIA 暗示他们不仅能对 BTB 这样做，还能对方向预测器这样做，从而使他们能够对具有动态行为的分支每周期执行更多预测。

Olympus 实现了具有稳健提前流水线机制的高级预测器，每周期预测次数比竞争对手高出多达 2.3 倍

-Vera 白皮书

使用 BTB 对进行预测允许在一个预测周期内预测两次取指

-AMD 的 Zen 5 优化指南

我尝试设置了一个测试，其中条件分支以极其可预测的方式在1/8的时间里不被采用。我希望这能迫使核心使用条件预测器，至少通过提前索引来验证BTB的输出。但如果这造成了影响，我在Zen 5或Olympus上都看不出来。如果需要使用分支预测器，两个核心都能每周期处理两个被采用的分支。我尝试过用更复杂的模式让分支被采用/不被采用，但在最初几次尝试导致两个核心都出现误预测后，我就没有再投入更多时间了。

NVIDIA进一步指出，与竞争对手相比，Olympus每周期能维持更多预测，并引用了具体的SPEC CPU2026整数工作负载。

验证这一点很困难，因为两种架构都没有提供硬件计数器来跟踪它们做了多少次预测。我也不认为每周期预测数本身是一个有用的指标，因为误预测之后的预测是无用的，而且如果前端已经得到充分供给，每周期更多预测可能不会影响性能。另一个因素是核心围绕每周期性能而非时钟速度的设计目标。Olympus可能平均每周期预测更多，但这可能是因为在给定周期数内，它比Zen 5推进了更多指令流。相比之下，Zen 5的设计目标是高频率，同时仍能维持每周期两个被采用的分支；计入时钟速度后，两种设计完成分支的速率相差并不太远。

指令取指

来自分支预测器的取指地址经过地址转换，使用一个64条目全相联指令TLB。随后Olympus从一个64 KB、4路组相联的指令缓存中取指，该缓存每周期可向48条目的解码队列输送128字节。一次128字节的取指最多可包含32条指令，这远远超过核心的解码吞吐量，可能是为了让前端在经历长延迟分支或误预测后遇到连续指令流时能够赶上。

更大的指令足迹也能得到良好处理，核心每周期可从L2缓存取指32B。单线程的每周期L2代码吞吐量在Olympus上远高于Zen 5或Cortex X925。与许多其他核心一样，如果指令溢出到L3，代码读取吞吐量会急剧下降。

在核心中运行两个线程会导致指令取指带宽在1 MB之前急剧下降，这表明Olympus正在静态划分L2缓存。即使兄弟线程运行的是一个由若干指令组成的简单循环，并且不进行任何可能导致数据侧缓存容量争用的内存访问，情况也是如此。即使另一个线程受延迟限制并停留在低IPC，高IPC线程（仅NOP）的吞吐量也会减半。重命名与分派

解码后的指令产生的微操作需要经过寄存器重命名，并在后端分配适当的跟踪资源。这一过程提供了执行其他优化的机会，比如移动消除。Olympus能在有限程度上进行移动消除。一条依赖MOV链的执行速度略高于每周期1条，表明某些MOV以零延迟执行。AMD的Zen 5令人印象深刻地能在每周期5条MOV上做到这一点。

如果核心运行两个线程，Olympus的每线程移动消除能力奇怪地变得更好。每线程依赖MOV吞吐量增加到每线程每周期1.7条MOV，或两个线程合计3.5条。Zen 5也有所改善，每核心吞吐量增加到每周期7条MOV。然而，这代表每线程吞吐量从每周期5条下降到3.5条。后端执行引擎

Olympus的后端几乎处处都有庞大的寄存器文件和队列。它有点像Cortex X925，但许多方面都更上一层。唯一条目数略低的结构是FP/向量寄存器文件，其条目数少于Zen 5。然而，Olympus通过经常让一个128位向量寄存器保存由不同指令写入的一对标量FP值来弥补。这是一个有用的优化，因为很多代码无法向量化。

用NOP进行测试为Olympus能够同时在途的指令数量设定了一个非常高的上限。核心可以将两个长延迟加载与它们之间间隔的1000多个NOP重叠，但实际在途指令数可能显著更低，因为Olympus只能分配略多于606个寄存器。约606个已分配寄存器的限制适用于架构寄存器侧，因为使用上述标量FP优化后，已分配架构寄存器的数量仍然上限为606。

Olympus的调度器布局与Arm Cortex X925类似。八个整数ALU被分成四对，每对由一个约25条目的调度队列供给。其中一对ALU比较特殊，可以处理不太常见的操作。Olympus和Cortex X925都使用六管FPU，同样为每对流水线配备一个调度队列。不过，NVIDIA在较小的调度队列之前使用了一个非调度队列，而Arm则使用了三个非常大的调度队列。

我检查过的所有后端结构都是静态分区的，这意味着当兄弟线程空闲时，每个线程只能获得结构容量的一半（或更少）。这甚至适用于调度队列，而在其他架构上，调度队列通常采用水位标记或竞争性共享。静态分区甚至延伸到执行单元，无论兄弟线程是否正在运行命中相同端口的指令，执行吞吐量都会减半。相比之下，AMD的SMT实现灵活共享大多数结构，不过它会设置限制（水位标记）以确保一个线程无法不公平地独占某项资源。

加载/存储

Olympus通过一组四条流水线执行内存访问，所有流水线都能处理加载，其中两条能处理存储。该核心的L1数据缓存标称延迟为四个周期，但简单的内存延迟测试可以测得2-3个周期的L1D延迟，这可能是因为值预测。

Olympus上的内存消歧行为与Arm或Intel Atom系列的较旧核心有更多共同之处。只要加载对齐到存储的任一半，Olympus就能从64位存储快速转发到依赖的32位加载。对于精确地址匹配，转发延迟为3-4个周期；转发上半部分时为5-6个周期。所有其他重叠情况都会导致12-13个周期的惩罚，很可能是因为核心阻塞了加载并等待存储提交。

当在64B缓存行中间的32B边界上进行存储转发时，Olympus会遇到一个奇怪的卡顿。奇怪的是，当访问跨越64B缓存行边界时，它不会以同样的方式卡顿，尽管每个64B对齐边界当然也是32B对齐的。此外，触及缓存行前32B半部分末尾同一32位块的独立加载和存储有时不被允许并行进行。

更宽的向量访问在中间的32B边界处表现出同样的奇怪行为，并且在进入缓存行的第一个16B对齐边界处表现出额外的卡顿。向量存储转发的延迟更高，这对许多核心来说是典型现象。

对于地址转换，Olympus有一个大型的112条目全相联数据TLB，由统一的3K条目L2 TLB作为后备。相比之下，Zen 5有一个96条目全相联数据TLB，由4K条目L2数据TLB作为后备。AMD不使用统一的L2 TLB，而是将指令侧转换存储在单独的2048条目L2指令TLB中。NVIDIA在我们可访问的系统上运行了一个使用64 KB页面的内核，与使用典型的4 KB页面相比，这扩展了TLB覆盖范围。64 KB页面基本上意味着地址转换延迟在许多测试中不是影响因素，但也使得直接比较变得困难。

缓存与内存访问

大型乱序结构、预取器、分支预测和值预测帮助核心容忍内存访问延迟。缓存则从另一侧解决问题，通过降低频繁访问地址的内存延迟。与NVIDIA之前的Grace CPU相比，Vera的缓存策略有了很大改进。Olympus的数据内存层次结构从一个大型的96 KB 6路组相联数据缓存开始，其容量比AMD、Arm和Intel服务器核心上常见的32、48或64 KB数据缓存更大。

L1未命中可以由一个2 MB 8路组相联L2捕获，其加载到使用延迟为10个周期。低周期数延迟意味着Olympus的L2提供数据的速度几乎与Cortex X925的12周期L2一样快，尽管X925的时钟速度更高，达到4 GHz。与Grace的Neoverse V2核心相比，拥有2 MB的L2容量是一个可喜的改进，后者只能使用1 MB的L2缓存。Vera的L3延迟与Grace相当，从绝对值来看并不出色，超过120个周期。然而，这对于在庞大的单片互连上实现L3缓存的设计来说是典型现象。Vera至少将L3容量从114 MB增加到了164 MB。

NVIDIA 通过激进的预取来弥补 L3 的高延迟。单线程的线性读取模式从 L3 达到 88.53 GB/s，应用利特尔法则表明 Olympus 能够维持 50-51 个对 L3 的未完成请求（88.53 GB/s /(64B 行 * 3.3 GHz) = 每周期 0.42 个缓存行，乘以 121.5 周期延迟 = 50.9 个在途请求）。对 Grace/GH200 做同样的计算得到 35-36 个在途请求。与许多其他核心一样，Olympus 的 L2 未命中队列可能比 L1 未命中队列更深。使用 Lemire 的内存级并行微基准测试表明，Olympus 可以有 18-19 个在途的需求 L1D 未命中。Lemire 的测试使用随机指针追逐模式，这种模式无法与 L2 预取器配合，因此不会利用更大的 L2 未命中队列。

Olympus 的 SMT 实现也为数据访问对 L1D 和 L2 缓存进行了分区，这意味着如果兄弟线程处于活动状态，每个线程只能获得所有核心私有缓存容量的一半。与指令侧一样，即使兄弟线程不进行任何数据侧访问，这种分区也适用。性能：SPEC CPU2026

SPEC CPU2026 分数显示，Olympus 为服务器核心提供了非常强大的单线程性能。在桌面环境中，它与 Intel 和 AMD 的最新核心相差不远，这里以 Core Ultra 9 285K 和 Ryzen 7 9800X3D 为代表。面对 Neoverse V2 和 Neoverse N2 等 Arm 服务器竞争对手，Olympus 毫不费力地取得了显著领先。这里的一个显著问题是，我们所能访问的测试系统上的内核使用 64 KB 页面，而所有其他结果都是用 4 KB 页面获得的。估计页面大小的影响会很困难，但我预计即使使用更小的页面大小，Olympus 仍能很好地与 Neoverse 同类产品相比。

检查单项分数显示，NVIDIA 在许多整数工作负载上表现良好，包括其白皮书中强调的那些（723.llvm_r、727.cppcheck_r、721.gcc_r、714.cpython_r）。Olympus 在 706.stockfish_r 中对 Zen 5 的大幅落后更多与指令集差异有关，而非核心架构，因为 Olympus 在该工作负载中执行的指令数大约是 Zen 5 的两倍。ISA 差异也影响了浮点侧的 772.marian_r。指令数也可能朝相反方向发展，aarch64 在 750.sealcrypto_r 中需要更少的指令，但 Zen 5 凭借其整体更高的吞吐设计（考虑时钟速度时）能够在那个工作负载中保持强劲性能。

Olympus 的目标是通过强调每时钟性能来实现高单线程性能，而性能计数器不出所料地表明 IPC 非常高。NVIDIA 的 IPC 通常高于 Zen 5，即使在 Zen 5 设法提供更高性能的工作负载中也是如此。

更宽的流水线难以供给，检查自顶向下性能事件显示，几乎所有工作负载平均都有超过 50% 的派发槽位未被使用。SPEC CPU2026 的整数工作负载损失了大量吞吐量，因为前端无法足够快地提供微操作（前端受限），这表明即使是快速的两步超前分支预测器和大型指令缓存也无法始终跟上。Zen 5 也是如此。

SPEC 的浮点工作负载往往更受后端限制，这意味着微操作无法派发，因为后端资源已满。换句话说，核心达到了其能够保持在途指令数量的限制因素。

“空间多线程”

SMT 是一种在第二个线程可用时收回未使用的核心宽度并更有效地利用后端资源的方法。NVIDIA 的“空间多线程”对 SMT 采取了相当非传统的方法，在查看 SPEC CPU2026 的整数工作负载时确实显示出前景。在那里，Olympus 的 SMT 收益与 Zen 5 相当。Zen 5 在实际性能上领先，但我在这里关注的是收益，因为客户端 CPU 预期要最大化每核心性能。

Olympus 的收益在浮点侧不太令人信服，尽管 SPEC CPU2026 的浮点套件仍享有显著的整体提升。

单项工作负载显示出不同的收益，Zen 5 或 Olympus 在不同的子测试中比对方从 SMT 中获得更多。然而，两个核心的总体模式是相同的。低 IPC、前端受限的工作负载（如 723.llvm）往往从 SMT 中获得巨大收益。较高 IPC、吞吐受限的工作负载（如 750.sealcrypto 和 714.cpython）收益较小。

SPEC CPU2026 的浮点套件往往更受后端限制，而 Olympus 的 SMT 实现在 709.cactus 和 782.lbm 上出人意料地遭受吞吐量损失。理想情况下，SMT 实现在使用两个线程时不应损失整体吞吐量，因此 Olympus 的空间多线程在这两个工作负载中似乎并不理想。Zen 5 在 SPEC 的浮点工作负载中从 SMT 获得的收益也较少，但设法避免了使用两个 SMT 线程会比串行运行两个任务更糟的情况。

SPEC CPU2017

SPEC CPU2017 仍然是一套有趣的测试套件，因为它包含了一些在 SPEC CPU2026 中没有对应项的困难工作负载。我手头还有更多 SPEC CPU2017 数据，包括来自我已无法再访问的系统的数据。这些数据显示，Olympus 击败了更多服务器核心，包括一个 Zen 5 服务器实现。它还显示，Olympus 与 AMD 顶级 Zen 4 桌面芯片打成平手，这对服务器核心来说是一项令人印象深刻的壮举。

由于存在会严重冲击分支预测器并受后端内存延迟拖累的工作负载，SPEC CPU2017 中的 SMT 收益甚至高于 SPEC CPU2026。505.mcf 就是一个例子。

Olympus 在浮点套件中再次出现了一些令人担忧的 SMT 性能损失。AMD 的 Zen 4 也未能幸免，但其损失相对较轻。3% 或 1% 的性能下降远非理想，但很可能不如 11.98% 或 9.78% 的损失那么明显。

解释 Olympus 的 SMT 行为很困难，因为分析 SMT 测试用例比查看单线程用例更难。709.cactus 的情况可以解释为：当核心在其 SMT 线程中运行该工作负载的两个副本时，L2 数据 MPKI 从 3.58 增加到 6.52。然后，后端中划分的资源可能不足以应对高 L3 延迟。

然而，我无法对 SPEC CPU2017 的 503.bwaves 和 549.fotonik3d 应用同样的解释。503.bwaves 在两种情况下都会反复冲击 L2，单线程时为 32.12 MPKI，运行两个线程时为 33.03 MPKI。自顶向下事件表明性能损失并非源于内存受限原因。549.fotonik3d 也遭受大量 L2 未命中（单线程为 52.45 MPKI，双线程为 57.13），但同样，相对差异并不太大。总体而言，Olympus 的空间多线程似乎在前端受限工作负载上能带来与传统 SMT 实现相当的强劲收益，但在处理后端受限工作负载时表现不佳。关于空间多线程的思考

NVIDIA 的空间多线程不太像传统的 SMT 实现，而更像是在运行两个线程时动态地将 Olympus 拆分为两个较小的核心。几乎每一类可想象的核心资源，直至 L2 缓存，都被静态划分，因此每个线程只能访问可用资源的一半。这种方法无疑简化了性能分析，因为将两个 SMT 线程视为两个 5 宽核心，比思考两个线程如何在例如 AMD 的 Zen 5 中动态使用各种核心资源要简单。我想这对核心设计方面也更容易。NVIDIA 不必调整确保线程公平性的复杂机制，因为将所有资源一分为二已经提供了公平性保证。

来自 NVIDIA 的 Vera 白皮书

我认为，空间多线程究竟是一个好主意，还是一种旨在简化 NVIDIA 第一代 SMT 实现的简化方案，目前尚无定论。空间多线程展现出前景，在 SPEC CPU 的整数工作负载中带来了与传统 SMT 实现相当的收益。在最好的情况下，Olympus 表明，如果你的核心资源一开始就足够庞大，那么你让两个线程共享资源的效率可能并不重要。然而，在 SPEC 的浮点测试中，后端受限场景下的收益可能不一致，甚至为负。很难判断这些粗糙之处是来自第一代 SMT 实现的初期问题，还是来自将每个线程锁定在半个核心中所产生的根本性低效。我想，SMT 收益的某一部分来自动态地让每个线程利用其兄弟线程未充分利用的资源，而限制每个线程这样做的能力可能会对 SMT 收益产生负面影响。

与任何架构特性一样，最好还是观望 NVIDIA 是否会继续采用同样的策略。成功的架构技术往往会在多代产品中延续，并在整个行业中得到采用。空间多线程是否会如此，谁也说不准。结语

Arm 早期的服务器芯片强调核心数量而非每核心性能，但随着更新的 Arm 核心瞄准更高的性能目标，Arm 服务器领域已经多样化。现在，NVIDIA 的 Vera 提供了顶级的单线程性能，扭转了局面。NVIDIA 现在反而是核心数量较低的一方（尽管 88 个核心从绝对意义上说仍然很多），而 AMD 的服务器芯片拥有更多核心但单线程性能较低。由于页面大小不同，SPEC 结果中存在一些误差空间，但我怀疑这只会缩小 Olympus 与最快的 AMD 服务器核心之间的差距，而不会改变它们的相对排名。

来自 NVIDIA 的 Vera 白皮书

面对 Arm Neoverse 的竞争，Olympus 在每核心吞吐量方面占据主导地位，这得益于其高单线程性能以及通过运行第二个线程来提高吞吐量的能力。当 Arm 核心根本无法同时运行第二个线程时，争论传统 SMT 方法与 Olympus 空间多线程的优劣就无关紧要了。在绝大多数情况下，Olympus 通过运行第二个线程获得吞吐量提升，而它获得的任何吞吐量提升都会扩大其与 Neoverse 同时代产品之间的每核心性能差距。NVIDIA 之前的 Grace 芯片也包含在这一比较中。Vera 相比 Grace 是巨大的进步，核心更快，核心也更多。

总体而言，Olympus 是一款非常令人兴奋的服务器核心。其性能展示了低频设计的优点，该设计旨在最大化每时钟周期完成的工作量，并且无疑推动了服务器单线程性能的边界。其他服务器核心设计者应当注意，因为即使服务器核心数量持续增加，低线程工作负载的性能仍然很重要。我期待看到 NVIDIA 进一步发展这款令人印象深刻的核心。

关于本文的讨论还有 18 条评论……

没有帖子

准备好了解更多了吗？