【问题标题】:Best event counter to use for measuring wall clock time using perf tools使用 perf 工具测量挂钟时间的最佳事件计数器
【发布时间】: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-cycles perf 事件会在核心时钟停止时停止。它与实际的 TSC 是分开的。 (现代英特尔上真正的硬件事件是cpu_clk_unhalted.ref_tsccpu_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


【解决方案1】:

您可以使用task-clock

这是进程运行时的明确挂钟时间,并且作为奖励是可移植的,因为它不依赖任何 PMU 事件。

【讨论】:

  • 你知道这个说法的权威来源吗,因为在互联网上快速搜索会发现很多关于它是什么的推测性和部分矛盾的陈述。
  • @Peter - 我认为任务时钟是挂钟时间(每个线程)毫无疑问。它也出现在默认事件列表中,并用于计算诸如 MHz 之类的派生指标,因此您可以非常确定它正常工作(不像说 cpu-clock)。如果您想要详尽的证据,您可能需要查看源代码。
猜你喜欢
  • 2013-04-10
  • 1970-01-01
  • 2013-07-04
  • 1970-01-01
  • 2023-03-24
  • 1970-01-01
  • 2012-08-08
  • 2023-03-03
  • 2023-04-05
相关资源
最近更新 更多