严谨的全系统时序仿真回归：打破性能模拟的“墙”

背景

准确的时序仿真（Timing Simulation）长期以来一直是计算机体系结构研究中最重要的工具之一。然而，随着现代计算平台的演进，基于周期的仿真（Cycle-level Simulation）正变得日益不切实际。

当今的系统架构极其复杂，集成了多核 CPU、深层内存层级、专用加速器、复杂的 I/O 子系统以及庞大的软件栈。这种复杂性导致详细仿真的速度极慢——往往需要耗费数月时间才能模拟出几秒钟的实际执行过程。这种“时序仿真墙”迫使研究人员转向近似方法，例如仅仿真应用程序、固定指令窗口，或使用仅代表工作负载的指令窗口。虽然这些方法缩短了运行时间，但它们通常牺牲了对真实微架构行为进行严谨端到端测量的能力。

本文主张回归严谨的全系统时序仿真，但不是通过始终对所有细节进行仿真，而是通过测量正确的执行区间、使用恰当的性能指标，并应用统计上可靠的方法，使准确的仿真重新变得可行。

核心内容

为什么需要全系统仿真？

全系统仿真模拟整个计算机系统，包括 CPU、内存、设备、操作系统和应用程序。与用户级仿真不同，它捕捉了整个软硬件栈的交互。全系统仿真至关重要，因为许多关键行为（如操作系统活动、中断、I/O、内存管理、同步和设备交互）并非仅由应用程序代码产生。忽略这些层级可能会歪曲真实的系统瓶颈和性能表现。

全系统仿真可追溯至 20 世纪 90 年代的 SimOS，随后影响了 Simics（现为 Intel Simics Simulator）、M5（集成在 gem5 中）以及 QEMU（用于 MARSS 和 QFlex）等平台。如今，全系统仿真因以下四个原因重新变得不可或缺：

1. 现代工作负载的服务化与多租户特性：依赖微服务、RPC、存储栈和由 OS 中介的交互。
2. 内核行为的核心地位：许多服务器和移动工作负载在操作系统中花费大量时间，内核行为成为性能分析的中心。
3. 异构系统的协调需求：现代系统越来越多地将 CPU 与 GPU、加速器和智能网卡结合，CPU 和 OS 负责协调、内存管理和同步。
4. Agentic AI 工作负载的需求：基于代理的 AI 工作负载严重依赖工具调用、调度、API、数据库和系统集成，使得 CPU 和 OS 行为对端到端性能至关重要。

因此，全系统仿真不再仅仅是遗留的方法论，由于整个系统栈已成为架构创新的目标，它变得日益必要。

时序仿真墙

仿真器在抽象程度、功能和性能上跨度很大。在最快速的一端，是使用 JIT 翻译的执行驱动型全系统仿真器，它们在运行时动态将目标 ISA 指令映射到主机 ISA。自 SimOS 早期系统以来，这些仿真器通常保持在接近原生硬件速度（约一个数量级差异）的范围内。

现代 ISA 仿真器（如 QEMU）还可以生成详细的执行轨迹用于功能仿真，从而分析缓存和 TLB 缺失率、分支预测器行为和预取器准确性。这种追踪相对于原生执行引入了另一个数量级的减速。

时序仿真器更进一步，对 CPU、加速器、内存和 I/O 设备中的微架构组件之间的周期级交互进行建模，导致仿真吞吐量显著降低。

以单个 ARM Neoverse N1 目标核心及其缓存层级在 AMD Zen 3 主机上运行服务器工作负载为例，仿真速度的下降层级如下：

1. QEMU 原始 ISA 仿真速度：基准速度。
2. 用户级功能仿真：由于 instrumentation（插桩）导致的速度下降。
3. 全用户级指令的微架构功能仿真：包括缓存层级、TLBs、前端表和数据预取器，速度进一步大幅下降。
4. 包含 OS 的全指令功能仿真：速度继续降低。
5. 时序仿真速度：最终的最慢速度。

测量什么指标？

时序仿真器计算周期，因此架构师常报告 IPC（每周期指令数）。对于单核工作负载，当大多数执行的指令对应于程序进展时，IPC 是合理的。

然而，对于多核工作负载，IPC 具有误导性。线程可能自旋、轮询、阻塞、等待锁、同步或执行不推进有用工作的 OS 代码。系统可能维持高 IPC 但几乎没有向前进展；实际上，总 IPC 可能会奖励“忙等待”。

因此，用户级 IPC（U-IPC） 通常是更好的代理指标。U-IPC 计算一段时间内的用户级指令，假设每个请求的用户指令大致稳定，且大多数自旋发生在 OS 中。在此假设下，U-IPC 比总 IPC 更直接地跟踪有用吞吐量。

但 U-IPC 必须针对每个工作负载进行验证。如果自旋发生在用户空间（例如具有用户级网络栈的系统），原始 U-IPC 仍会计算非生产性工作，必须修正以排除自旋。更广泛的要求是指标验证：严谨的仿真方法论必须证明所选指标（IPC、U-IPC、吞吐量或延迟）确实捕捉到了所研究工作负载的向前进展。

如何测量？

由于时序仿真墙，研究人员常使用简化的测量方法。最常见的方法是测量单个 1 亿到 10 亿指令的单位。然而，取决于固定测量取自执行的哪个位置，这种方法可能导致结果不明确，甚至得出错误结论。

设计师通常使用采样来捕捉性能估计中的变异性。基于阶段的采样（如 SimPoint）是一种流行技术，它使用基本块向量（BBV）的聚类来选择代表性的应用程序“阶段”。这种采样能正确捕捉构成大部分执行的重复指令流。

然而，基于阶段的采样可能忽略 OS 效应、中断和 I/O 交互、核心间通信以及软件故障。此外，Wunderlich 在其论文中指出，基于阶段的采样：(1) 错过了较少见指令流的微架构足迹及其对性能的影响；(2) 放弃了任何带有置信度的估计误差界限。

一种严谨的采样技术是统计采样（如 SMARTS），它取大量（例如数百个）小（例如 200k 周期）、均匀间隔且代表执行整体而非特定阶段的测量单元。

确定测量窗口

现代工作负载并非相似指令的稳定流。由于网络活动、资源争用、后台 OS 活动、同步效应、软件故障、DVFS 节流、UI 和图形活动以及其他异步事件，其性能随时间波动。

Alameldeen 等人提出了一种统计上严谨的方法论，以确定在指定误差范围和置信水平内捕捉工作负载性能变异性所需的最小测量窗口。

与具有规定测量窗口的传统数据库工作负载（如 TPC 基准测试）不同，研究中使用的典型基准测试和工作负载没有规定窗口。应用 Alameldeen 的方法论，我们发现，为了捕捉单个 ARM Neoverse N1 核心及其缓存层级在 CloudSuite、DCPerf 和 DeathStarBench 等服务器工作负载中的性能变异性，需要 5 到 120 秒的目标执行时间。

使用当今最快的周期精确仿真器 gem5，以 250 KIPS 的速度仿真单个核心的几秒钟，需要数月的仿真时间。

关键要点

• 全系统仿真的必要性回归：由于现代工作负载（特别是 AI 和微服务架构）对 OS、I/O 和异构硬件协调的高度依赖，仅仿真应用程序已不足以反映真实性能，全系统仿真成为架构创新的必要工具。
• 打破“时序仿真墙”的策略：不应试图对所有细节进行全时段仿真，而应通过“测量正确的执行区间”和“应用统计方法”来提高可行性。
• 性能指标的陷阱与修正：
  • 在多核环境中，总 IPC 可能因“忙等待”而失真。
  • 用户级 IPC（U-IPC）是更好的吞吐量代理，但需验证是否排除了用户空间的自旋开销。
  • 必须对任何选定的指标进行验证，确保其真正捕捉到了“向前进展”。
• 采样方法的优劣对比：
  • 固定窗口/阶段采样（如 SimPoint）：简单但可能忽略 OS 交互、中断及罕见指令流的影响，且缺乏误差界限。
  • 统计采样（如 SMARTS）：通过大量均匀间隔的小样本单元，能