现代系统中的噪声
硬件和软件中有许多旨在提升性能的特性，但并非所有特性的行为都是确定性的。以动态频率缩放（DFS, Dynamic Frequency Scaling）为例，该特性允许 CPU 将频率提升到远高于基础频率的水平，使其能够显著加快运行速度。DFS 通常也被称为超频（turbo）模式。遗憾的是，CPU 无法长时间保持在超频模式下运行，否则可能面临过热风险。因此，一段时间后，CPU 会降低频率以保持在其热设计功耗（TDP）范围内。DFS 通常在很大程度上依赖于当前系统负载和外部因素（如核心温度），这使得预测其对性能测量的影响变得困难。
图 FreqScaling 展示了一个典型示例，说明 DFS 如何导致性能方差（performance variance）。在我们的场景中，我们在一个"冷"处理器1上先后启动了两次基准测试。在第一秒内，第一次测试迭代以 4.4 GHz 的最大超频频率运行，但随后 CPU 不得不将频率降低到 4 GHz 以下。第二次运行没有 CPU 频率提升的优势，没有进入超频模式。尽管我们运行了完全相同版本的基准测试两次，但它们运行的环境并不相同。如你所见，由于第一次测试在初始阶段以更高的 CPU 频率运行，因此比第二次快 200 毫秒。当你在笔记本电脑上对软件进行基准测试时，这种情况经常发生，因为笔记本电脑的散热能力有限。4
动态频率缩放引起的性能方差：第一次运行比第二次快 200 毫秒。
频率缩放是硬件特性如何导致测量结果产生变化的一个例子，但软件也可能带来类似影响。考虑对 git status 命令进行基准测试，该命令会访问磁盘上的许多文件。在这个场景中，文件系统（filesystem）扮演着重要角色，特别是文件系统缓存（filesystem cache）。第一次运行时，文件系统缓存中缺少所需条目，缓存不起作用，git status 命令运行得非常慢。然而第二次运行时，文件系统缓存已经预热，速度会比第一次快得多。
你可能正在考虑在正式测量前进行一次空跑（dry run）。这固然有帮助，遗憾的是，测量偏差也可能在多次运行中持续存在。[Mytkowicz09] 论文证明，UNIX 环境大小（即存储环境变量所需的总字节数）或链接顺序（提供给链接器的目标文件顺序）可能以不可预测的方式影响性能。还有许多其他内存布局影响性能测量的方式。2
保持一致的性能需要在相同条件下运行所有基准测试迭代。在基准测试的每次运行中实现 100% 一致的结果是不可能的，但通过仔细控制环境，也许可以接近这个目标。消除系统中的不确定性有助于进行定义明确、稳定的性能测试，例如微基准测试。
考虑这样一个场景：你实现了一项代码变更，想通过对"变更前"和"变更后"版本的程序进行基准测试来了解相对加速比。在这个场景中，你可以控制系统中的大多数变量，包括硬件配置、操作系统设置、后台进程等。禁用具有不确定性性能影响的特性，将有助于你获得更一致、更准确的对比结果。你可以在附录 A 中找到此类特性的示例及禁用方法。此外，还有一些工具可以设置环境以确保基准测试结果的低方差，temci14 就是其中之一。
然而，完全复制相同的环境并彻底消除偏差是不可能的：可能存在不同的温度条件、电源输出波动、意外的系统中断等。追逐系统中所有潜在的噪声和变化来源可能是一个永无止境的工作。有时根本无法实现，例如，当你对大型分布式云服务进行基准测试时。
当你想测量变更对真实世界性能的影响时，不应消除系统的不确定性行为。是的，这些特性可能会导致性能不稳定，但它们的设计目的是提升系统的整体性能。你的应用程序用户很可能启用了这些特性以获得更好的性能。因此，当你分析生产应用程序的性能时，应尽量复制目标系统配置——即你正在为之优化的配置。对系统引入任何人为调整都会导致结果与你的服务用户在实践中看到的情况有所不同。3
1. "冷"处理器是指在空闲模式下运行了一段时间、已充分冷却的 CPU。 ↩
2. [Curtsinger13] 中提出了一种能够进行统计上可靠的性能分析的方法。该研究表明，通过在运行时反复随机化代码、栈和堆对象的放置位置，可以消除来自内存布局的测量偏差。可惜的是，这些想法没有得到更广泛的推广，目前这个项目几乎已被放弃。 ↩
3. 禁用不确定性性能特性的另一个缺点是会使基准测试运行时间更长。这对于有时间限制的持续集成与持续交付（CI/CD）性能测试尤为重要，因为要求整个基准测试套件在一定时间内完成。 ↩
4. 请记住，即使是运行 Windows 任务管理器或 Linux top 程序，也可能影响测量结果，因为这会激活额外的 CPU 核心并分配给它。这可能影响运行实际基准测试的核心的频率。 ↩
14. Temci - https://github.com/parttimenerd/temci。 ↩