【发布时间】:2020-05-28 02:56:11
【问题描述】:
简单而复杂的问题:
使用什么计数器来获取性能工具来测量挂钟时间?
作为基线,我认为在分析代码时需要测量的第一件事就是挂钟时间,以便初步了解代码大部分时间在哪里。 我不在乎它是 IO 还是带宽受限或其他什么我只想知道它慢的地方。
听起来很简单的要求,但是现代 CPU 为高效工作而采取的许多技巧(如频率缩放等)以及 perf 中提供的大量不同(没有很好记录的)性能计数器,并不容易确定衡量正确的事情。
目前我这样做:
perf record -g -e ref-cycles -F 999 -- <cmd>
我认为这是未缩放的 CPU 频率,因此与部分代码运行的挂钟时间量成正比。但是谁知道呢?
【问题讨论】:
-
是的,现代 CPU 上的 ref-cycles 以恒定速率 始终 滴答,即使在核心时钟停止时也是如此。 (CPU 功能是
constant_tsc(和nonstop_tsc,这实际上是相同的功能位:How to get the CPU cycle count in x86_64 from C++?)。)当然还有基于内核测量的CPU 时间的软件事件task-clock。 IDK 是否行得通。 -
哦,但是
ref-cyclesperf 事件会在核心时钟停止时停止。它与实际的 TSC 是分开的。 (现代英特尔上真正的硬件事件是cpu_clk_unhalted.ref_tsc或cpu_clk_unhalted.ref_xclk_any)。甚至时钟停止以更改 CPU 频率也会影响它:Lost Cycles on Intel? An inconsistency between rdtsc and CPU_CLK_UNHALTED.REF_TSC。这是针对不休眠的工作负载。所以ref-cycles适合查找 CPU 热点,但不适用于 I/O 等待的整体配置文件。 -
您对测量一般 WCT 有什么建议吗?是否有任何事件可以读取 TSC?还是这种方法总体上是错误的想法?
-
好的。我想我误解了你的评论。您是说 cpu_clk_unhalted.ref_tsc 是我正在寻找的,还是说它受停机的影响?
-
我的第一条评论是部分脑放屁,第二条评论是更正。我想我应该删除/重新发布一个更正的版本。
标签: profiling performancecounter perf intel-pmu