我有一个 python 脚本(在 Linux fwiw 下运行)，我想通过以不同方式重写一些瓶颈部分来加快速度，看看哪一个更好/更快。
我可以测量运行时间或使用 cProfile 检测它，但问题是我使用的是现代笔记本电脑/CPU。从运行到下一次的运行时间变化高达 5% - 据我所知，这是由于各种形式的 CPU 节流(温度/功率)造成的。
这使得检查实际代码性能差异变得非常困难。是否有某种方法可以弥补这一点和/或轻松测量 CPU 完成的实际工作？
最佳答案
禁用 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 或其他具有可以使用硬件性能计数器的方便分析器的操作系统，那么这会很方便。 (通常仅适用于裸机，不适用于虚拟机；大多数虚拟机不会虚拟化性能监控单元。)
如果 L3 缓存未命中是性能成本的重要组成部分，您会期望核心时钟周期随频率而变化，同样是因为与 CPU 核心相比，RAM 变得相对更快/更低的延迟，这意味着乱序执行可以隐藏更多缓存未命中的延迟。
另请参阅Idiomatic way of performance evaluation?用于与保持频率稳定无关的其他基准考虑因素。
参见Why can't my ultraportable laptop CPU maintain peak performance in HPC这是一个很好的例子，展示了超可移植笔记本电脑在运行高功耗负载时的 CPU 频率与时间的关系，以及这种情况的 CPU 设计原因。
关于performance - 在现代 CPU 上进行基准测试时如何考虑节流问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/70316068/