回归严谨的全系统时序仿真
摘要
这篇博客文章主张在计算机体系结构中回归严谨的全系统时序仿真,以克服“时序仿真墙”并准确捕捉现代系统行为,提倡使用统计上可靠的方法测量正确的执行区间,而不是详细仿真一切。
暂无内容
查看缓存全文
缓存时间: 2026/06/17 23:44
# 严谨全系统时序模拟的回归
来源:https://www.sigarch.org/the-return-of-rigorous-full-system-timing-simulation/
## 严谨全系统时序模拟的回归
准确的时序模拟仍是计算机体系结构中最核心的工具之一,但现代系统已使周期级模拟愈发不切实际。当今平台集成了多核CPU、深层存储层次、加速器、复杂I/O和庞大的软件栈,使得精细模拟极其缓慢——模拟数秒的执行往往需要数月时间。这道“时序模拟墙”迫使研究者转向近似方法,例如仅模拟应用程序、固定指令窗口、或仅代表工作负载的指令窗口。这些方法虽缩短了运行时间,却常常牺牲了对真实微架构行为的严格端到端测量。
本文主张回归严谨的全系统时序模拟——不是时刻对所有细节进行模拟,而是通过测量正确的执行区间、采用合适的性能指标、并应用统计上可靠的方法,使精确模拟重新具备可行性。
## 为何需要全系统模拟?
全系统模拟模拟整个计算机系统:CPU、内存、设备、操作系统和应用程序。与用户级模拟不同,它捕捉了完整软硬件栈之间的交互。全系统模拟之所以重要,是因为许多关键行为源于操作系统活动、中断、I/O、内存管理、同步和设备交互——而非仅由应用程序代码产生。忽略这些层次可能会错误地反映真实系统瓶颈和性能。
全系统模拟的历史可追溯至1990年代的SimOS(https://en.wikipedia.org/wiki/SimOS),随后影响了Simics(https://en.wikipedia.org/wiki/Simics)(现为Intel Simics Simulator(https://www.intel.com/content/www/us/en/developer/articles/tool/simics-simulator.html))、M5(集成入gem5(https://dl.acm.org/doi/10.1145/2024716.2024718))以及QEMU(https://www.qemu.org/)(用于MARSS(https://ieeexplore.ieee.org/document/5982026)和QFlex(https://qflex.epfl.ch/))。
如今,全系统模拟再次变得不可或缺,原因有四:
1. 现代工作负载面向服务且多租户,依赖微服务、RPC、存储栈和操作系统中介的交互。
2. 许多服务器和移动工作负载在操作系统中花费大量时间,使得内核行为成为性能分析的核心。
3. 异构系统越来越多地将CPU与GPU、加速器和智能网卡结合,CPU和操作系统负责协调、内存管理和同步。
4. 代理型AI工作负载高度依赖工具调用、调度、API、数据库和系统集成,使得CPU和操作系统行为对端到端性能至关重要。
因此,全系统模拟不再仅仅是传统方法——它正变得越来越必要,因为整个系统栈已成为架构创新的目标。
## 时序模拟墙
模拟器在抽象层次、功能和性能上跨度很大。最快的一端是执行驱动的全系统模拟器,它们使用JIT翻译在运行时将目标ISA指令动态映射到宿主机ISA。自SimOS等早期系统以来,这些模拟器通常能在一个数量级内接近原生硬件速度。
现代ISA模拟器如QEMU还能生成详细的执行迹线,用于功能模拟,从而分析缓存和TLB失效率、分支预测器准确度和预取器精度。这种迹线引入相对于原生执行又一个数量级的降速。
时序模拟器更进一步,建模CPU、加速器、内存和I/O设备中微架构组件之间的周期级交互,导致模拟吞吐量大幅降低。下表比较了单个ARM Neoverse N1目标核心及其缓存层次结构运行服务器工作负载时,在AMD Zen 3宿主机上的模拟速度。第一行显示QEMU的纯ISA模拟速度。第二行显示因用户级功能模拟的插桩而导致的降速。第三行展示了对所有用户级指令进行功能模拟微架构组件(包括缓存层次结构、TLB、前端表和数据预取器)时的速度影响。第四行显示对所有指令(包括操作系统)进行功能模拟的影响。最后,第五行显示时序模拟速度。
现代工作负载并非稳定流式指令。其性能随时间波动,原因包括网络活动、资源竞争、后台操作系统活动、同步效应、软件卡顿、DVFS调频、UI和图形活动以及其他异步事件。Alameldeen等人(https://ieeexplore.ieee.org/abstract/document/1183520)提出了一种统计上严格的方法,用于确定在指定误差界和置信水平下捕捉工作负载性能变异性的最小测量窗口。
与传统数据库工作负载(如TPC基准测试)有规定的测量窗口不同,研究中使用的典型基准测试和工作负载通常没有。应用Alameldeen的方法,我们发现捕捉单个ARM Neoverse N1核心及其缓存层次结构的性能变异性,需要5到120秒的目标执行时间(涉及CloudSuite、DCPerf和DeathStarBench中的服务器工作负载)。以目前最快的周期精确模拟器gem5(250 KIPS)模拟单核心的几秒钟执行,就需要数月的模拟时间。
## 应该测量什么?
第二个问题是选择哪个性能指标。时序模拟器统计周期,因此架构师常报告IPC(每周期指令数)。对于单核工作负载,当大多数执行指令对应程序进展时,IPC是合理的。
然而,对于多核工作负载,IPC可能具有误导性(https://dl.acm.org/doi/10.1109/MM.2006.73)。线程可能空转、轮询、阻塞、等待锁、同步或执行不推进有用工作的操作系统代码。因此,系统可能在维持高IPC的同时没有太大进展;实际上,总IPC可能奖励忙等待。
这就是为何用户级IPC(https://ieeexplore.ieee.org/document/1677500)(U-IPC)通常是更好的代理指标。U-IPC统计一段时间内的用户级指令数,假设每个请求的用户指令数大致稳定,且多数空转发生在操作系统中。在此假设下,U-IPC比总IPC更直接地追踪有效吞吐量。
但U-IPC必须针对每个工作负载进行验证。如果空转发生在用户空间(例如使用用户级网络栈的系统),原始U-IPC仍会统计非生产性工作,必须修正以排除空转。因此,更广泛的要求是指标验证:严格的模拟方法必须证明所选指标(IPC、U-IPC、吞吐量或延迟)确实能捕捉所研究工作负载的前进进度。
## 如何测量?
由于时序模拟墙的存在,研究者常采用缩略测量。最常见的技术是测量单个1亿到10亿指令的单元。不幸的是,取决于固定测量在执行中的位置,该技术可能得出不确定的结果,甚至错误的结论。
相反,设计者常使用采样来捕捉性能估计的变异性。基于阶段的采样,例如SimPoint(https://dl.acm.org/doi/10.1145/885651.781076),是一种流行技术,利用基本块向量(BBV)的聚类来选择具有代表性的应用程序“阶段”。这种采样能正确捕捉代表大部分执行过程的重复指令流。
虽然简单实用,但基于阶段的采样可能忽略操作系统效应、中断和I/O交互、核心间通信以及软件卡顿。此外,Wunderlich(https://users.ece.cmu.edu/~jhoe/distribution/2010/wunderlich.pdf)在其论文中指出,基于阶段的采样:(1) 遗漏了较少出现的指令流的微架构足迹及其对性能的影响;(2) 放弃了估计误差的置信边界。
一种严格的采样技术是统计采样,例如SMARTS(https://ieeexplore.ieee.org/document/1206991),它采集大量(例如数百个)微小的(例如20万周期)、均匀间隔的测量单元,代表执行的总体特征,而非工作负载的阶段。该技术能够限制估计误差并提供可量化的置信度。它还开启了丰富的统计采样工具,用于在估计置信度与测量速度之间进行权衡,并量化样本偏差以检测估计偏差。
下图比较了三种缩略测量技术的性能估计误差幅度,这些测量基于对双核插槽(2.0 GHz ARM Neoverse N1核心)运行单层、多层和整合服务器工作负载(CloudSuite、DCPerf和DeathStarBench)的完整时序模拟运行进行的数十分钟目标时间测量。图中比较了相对于完整时序基线的误差:(1) 每个核心从最小测量窗口内三个等距位置(即起始点、1/3处、2/3处)开始的单次10亿指令单元;(2) 100目标微秒单元(即2.0 GHz时钟下的20万周期),包括基于K-means聚类的基本块向量(BBV);(3) 基于统计采样抽取的(数百个)100目标微秒均匀样本,误差界为5%,置信度为95%。
10亿指令单元和BBV两者的估计误差都很高,前者不具有执行代表性,后者仅代表频繁执行的指令。相比之下,统计采样实现了所需的误差界和置信度,因为它不仅代表频繁执行的指令,还代表那些因微架构足迹而对性能具有高影响力的指令。
## 先进采样框架
下图展示了一个采用QFlex 3.0(https://qflex.epfl.ch/)(源自SimFlex(https://dl.acm.org/doi/abs/10.1109/MM.2006.79))的先进采样框架,用于ARM ISA的全系统时序模拟。对于每个工作负载,首先在真实平台上加载并预热软件栈及操作系统,然后通过测试确定最小窗口(例如5到120个目标机秒),称为“总体”,使用Alameldeen等人(https://ieeexplore.ieee.org/abstract/document/1183520)的技术。接着再次加载工作负载,这次使用QEMU并通过功能模拟器运行,平均速度约6 MIPS,持续整个总体时长。
功能模拟器模拟所有具有长期状态的微架构组件(例如缓存层次结构和TLB、分支表、数据预取器),并定期将包含架构和微架构状态的检查点转储到检查点库中。由于功能模拟器不是周期精确的,它需要对时间进行近似。最常见的近似是IPC=1(https://dl.acm.org/doi/10.1145/2063384.2063454)或从相邻单元(https://ieeexplore.ieee.org/abstract/document/6522340)推导出的IPC。
检查点库中的检查点随后使用时序模拟器独立并行地运行100微秒。每个检查点首先运行一段有界时间窗口(例如200微秒)以确保具有短期状态的微架构组件(例如流水线缓存、缓存层次结构和NoC)预热,然后进行测量。接着聚合时序结果,以确定样本(即检查点数量)是否足够大,能在所需置信水平下限制误差(例如5%误差,95%置信度)。如果不够,采样框架会创建一个新的检查点库,缩短检查点之间的间隔。
## 挑战与开放问题
即使有精确的测量技术,采样(无论是基于阶段还是统计采样)仍面临根本性挑战。
1. **精确的状态生成**。功能模拟期间由时序引发的活动及其对微架构足迹的影响,可能因时间近似而导致显著偏差。在多线程工作负载的多层和整合场景中,这一挑战更为突出,因为线程间的性能差异会显著影响共享微架构足迹。
2. **功能模拟墙**。采样最小化了时序模拟器的测量需求,但将瓶颈转移至功能模拟器(6 MIPS的速度仅比250 KIPS的时序模拟器快24倍)。并行化功能模拟可能是实现多核宿主可扩展性的有前途方法。并行模拟从根本上受限于目标线程之间通信的粒度。
3. **检查点支持**。每次测量都生成和恢复整个检查点在存储容量和运行时开销上都不切实际。因此,实用采样需要增量检查点存储和恢复。
4. **非平均指标采样**。统计采样适用于平均类指标(如IPC或U-IPC),但较难应用于极端或罕见事件指标,例如最高温度(https://ieeexplore.ieee.org/abstract/document/6522340)、最差功耗(https://users.ece.cmu.edu/~jhoe/distribution/2010/wunderlich.pdf)或罕见延迟尖峰。
5. **捕获服务级指标**。请求延迟或p99.9延迟等指标,其粒度远大于IPC或U-IPC所需的采样单元。捕获服务级指标和尾部延迟可能需要数量级更大的总体和采样单元,这对功能模拟和时序模拟都构成挑战。
6. **多节点全系统模拟**。许多现代工作负载分布在多台机器上。单节点模拟通常不足以捕捉数据中心规模的行为,但尽管已有进展(https://ieeexplore.ieee.org/document/7975287),严谨的多节点全系统时序模拟仍是开放挑战。
7. **模拟器间的互操作性**。一个实用的生态系统应允许一个工具生成检查点库,另一个工具执行时序模拟。这种互操作性需要一种接口定义语言,使模拟器之间能够交换可互操作的架构和微架构状态。
## 关于作者
**Shanqing Lin**是EPFL计算机与通信科学学院的博士最后一年学生,也是QFlex v3.0的主要开发者。
**Mohammad Alian**是康奈尔大学电气与计算机工程系的助理教授。
**Babak Falsafi**是EPFL(epfl.ch)计算机与通信科学学院教授,也是瑞士数据中心效率协会(sdea.ch)创始主席。
**免责声明:** *这些文章由个人撰稿人撰写,旨在分享他们对计算机架构今日博客的见解,以惠及社区。博客中的任何观点或意见均为个人观点,仅代表博客作者本人,并不代表*
相似文章
BitCal-TTS:面向量化推理模型的比特校准测试时扩展
本文介绍了 BitCal-TTS,这是一种运行时控制器,通过在测试时扩展期间校准置信度信号,提高了量化推理模型的准确性并减少了过早终止的问题。
SwiftCTS:基于少样本校准的跨设计快速预测与时钟树指标帕累托优化
SwiftCTS是一个物理信息代理框架,利用梯度提升集成和少样本校准,快速预测并帕累托优化未见设计上的时钟树指标(功耗、线长、时钟偏移),以极少的训练数据实现高精度。
Alpha-RTL:用于 RTL 硬件优化的测试时训练
Alpha-RTL (TTT-RTL) 引入了一种用于 RTL 硬件优化的测试时训练框架,利用带有 EDA 反馈的强化学习来优化 LLM 生成的设计。它在基准测试上实现了显著的 PPA 减少。
认识爱丽丝。爱丽丝没耐心
这篇博文解释了系统延迟和恢复时间测量中的检查悖论,说明了为什么客户经历的平均等待时间比服务指标显示的要长。文中包含一个交互式模拟,并强调了理解分布尾部的重要性。
回归构建模块的构建模块
本文类比了C/C++中的安全漏洞与Verilog中的安全漏洞,指出硬件描述语言的设计导致了缺陷,并认为行业应投资于更安全的替代方案,类似于软件领域对内存安全编程语言的推动。