在现代 CPU 上进行基准测试时，如何解决节流问题？答案

【问题标题】：How can I account for throttling while benchmarking on a modern CPU?在现代 CPU 上进行基准测试时，如何解决节流问题？
【发布时间】：2022-01-15 19:52:35
【问题描述】：

我有一个 python 脚本（在 Linux fwiw 下运行），我想通过以不同方式重写一些瓶颈部分来加快速度，以查看哪个更好/更快。

我可以使用 cProfile 测量运行时间或对其进行检测，但问题是我使用的是现代笔记本电脑/cpu。从运行到下一个的运行时间变化多达 5% - 据我所知，这是由于各种形式的 CPU 节流（温度/功率）。

这使得检查实际代码性能差异变得非常困难。有什么方法可以弥补这一点和/或轻松测量 CPU 完成的实际工作吗？

【问题讨论】：

热节流并不是可以解释这种差异的唯一原因（尽管它起着重要作用）。事实上有减速的来源。这包括例如上下文切换（例如，浏览器是干扰运行基准测试的好应用程序，但即使像 ssh 连接这样的事情也可能产生微小的影响）、分配的内存对齐、代码本身的地址、分配的页面在虚拟和物理中的分布内存、操作系统调度和操作系统自身内部数据结构的行为，更不用说 I/O。
This talk 部分解释了这一点，并提供了一种工具来更好地处理这种统计噪音。并非所有减速源都可以消除。许多处理器不提供设置固定频率的方法，并且主流操作系统在性能方面远非稳定（实时系统更好）。 HPC 系统通常通过仅运行少数关键进程、调整操作系统（例如减少内核调用、线程绑定）和处理器配置（例如频率和内存控制）来成功地将噪声降低到 1-2%。

标签： performance benchmarking

【解决方案1】：

禁用 turbo 或其他供应商所称的升压时钟可能是可行的，因此时钟频率保持在笔记本电脑可以承受的基准频率。

使 CPU 运行得更慢（比如 1.6GHz 而不是 3GHz 或其他）会改变 DRAM 缓存未命中与分支错误预测的相对成本，因为 DRAM 仍然需要类似数量的纳秒，但时钟要少得多循环。因此，如果您要比较的事物涉及这种权衡，那么它并不完美。对于 I/O 与 CPU 也是如此。

如果您可以让您的系统在几个不同的低但稳定的频率下运行，那么即使对于对内存延迟和带宽敏感的工作负载，您也可以推断出更高频率下的性能：Dr. Bandwidth解释如何在a blog article with slides from his HPC conference talk on it 中。

对于大多数受 CPU 限制的东西（不是内存或 I/O），perf stat ./my_program 可能很有用：以核心时钟周期而不是秒来查看时间。这甚至不会尝试控制缓存未命中成本与核心效应之间的相对差异，但如果您使用的是 Linux 或其他具有可以使用硬件性能计数器的便捷分析器的操作系统，则很方便。（通常只在裸机上工作，而不是在 VM 中；大多数 VM 不虚拟化性能监控单元。）
如果 L3 缓存未命中是性能成本的重要组成部分，您会期望核心时钟周期随频率而变化，同样因为与 CPU 核心相比，RAM 变得相对更快/延迟更低，这意味着乱序 exec 可以隐藏更多的缓存未命中延迟。

另请参阅Idiomatic way of performance evaluation?，了解与保持频率稳定无关的其他基准注意事项。

请参阅Why can't my ultraportable laptop CPU maintain peak performance in HPC，了解超便携笔记本电脑在运行高耗电负载时 CPU 频率与时间的关系，以及 CPU 设计原因。

【讨论】：

如果您可以在不同的频率下运行（即使它们都低于您想要的），则可以对更高频率的性能进行准确的推断。见sites.utexas.edu/jdm4372/2020/04/02/…。