Linux perf stat 怎样比较不同运行参数的硬件计数器

比较同一个程序的不同运行参数时，perf stat 最容易被误用成“各跑一次，看哪个数字小”。更稳妥的做法是先固定硬件事件集合、运行次数和采集边界，只让参数组合发生变化，再把每次运行的计数器、平均值和波动保存成可比较记录。

官方地址：https://man7.org/linux/man-pages/man1/perf-stat.1.html

真正可比的不是两行孤立的硬件计数器，而是“同一事件集合 + 同一运行方式 + 同一采集范围 + 可追溯参数标签”形成的一组实验记录。

先把比较实验的输入固定下来

假设要比较程序的两个参数组合：--mode=buffered 和 --mode=direct。实验的第一个版本不要同时更换输入文件、事件集合、CPU 范围和编译产物，否则最后的差异无法归因。perf stat 的基本职责是围绕一条命令采集性能计数器，事件由 -e 指定。

# 两组参数共享完全相同的输入文件和硬件事件集合
EVENTS="cycles,instructions,cache-misses"
INPUT="./bench-input.dat"

# 先把命令模板和参数标签分开，便于后续保存到比较表
./worker --input "$INPUT" --mode=buffered
./worker --input "$INPUT" --mode=direct

上面只是待测命令模板，不代表已经在本机执行。实际采集时，EVENTS、输入文件、二进制版本和工作目录都应保持一致；参数标签则要进入输出文件名或记录字段，否则多次运行后很容易把结果配错。

用同一组硬件事件采集每个参数组合

确定输入后，再让每个参数组合经过同一条 perf stat 命令。为了让结果适合后处理，可以显式写出事件并把输出重定向到独立文件：

# buffered 组：事件、输入和输出格式与其它组保持一致
perf stat -e cycles,instructions,cache-misses \
  -- ./worker --input ./bench-input.dat --mode=buffered \
  2> results-buffered.txt

# direct 组：只改变待比较参数，避免实验变量漂移
perf stat -e cycles,instructions,cache-misses \
  -- ./worker --input ./bench-input.dat --mode=direct \
  2> results-direct.txt

把输出放到标准错误文件是因为 perf stat 的统计信息通常写到标准错误；示例中的 2> 只是保存采集文本，不是把程序的标准输出当成计数器。若事件名在当前 CPU 上不可用，命令可能报告打开事件失败，此时不能把缺失事件当成零值继续比较。

事件集合越长，硬件计数器不一定能一次容纳全部事件。工具可能通过 multiplex 在不同时间片轮换计数器；这会影响精度和可比性。对于关键结论，应优先缩小事件集合，或把实验拆成几组固定事件重新采集。

用重复运行把单次偶然值变成可比较记录

单次运行很容易受到调度、缓存状态和输入路径的影响。perf stat 的 -r/--repeat 可以重复执行命令并给出平均值和标准差，--table 还能展示各次运行的时间表。比较参数时，两组必须使用相同的重复次数：

# 每个参数运行 8 次，并展示各次时间与最终统计
perf stat --repeat 8 --table \
  -e cycles,instructions,cache-misses \
  -- ./worker --input ./bench-input.dat --mode=buffered \
  2> results-buffered-repeat.txt

# 对照组使用同样的重复次数和事件集合
perf stat --repeat 8 --table \
  -e cycles,instructions,cache-misses \
  -- ./worker --input ./bench-input.dat --mode=direct \
  2> results-direct-repeat.txt

这里的平均值用于描述一组运行的中心位置，标准差用于提醒你结果是否稳定。若两组均值差异很小，但波动范围很大，应先增加实验控制或重复次数；不要把一次偶然的低值写成参数带来的收益。

用结构化输出保存参数标签和结果字段

如果只把终端文本复制到聊天窗口，后续很难批量比较。-x 可以指定字段分隔符，便于把计数器导入表格或脚本；也可以按当前 perf 版本支持的 JSON 输出选项保存机器可读记录。关键是让参数标签和输出文件一一对应：

# 用分号作为字段分隔符，减少逗号事件列表带来的歧义
perf stat --repeat 8 -x ';' \
  -e cycles,instructions,cache-misses \
  -- ./worker --input ./bench-input.dat --mode=buffered \
  2> results-buffered.csv

# 文件名和旁边的参数清单共同构成可追溯标签
printf '%s\n' 'label=buffered' 'input=bench-input.dat' \
  'events=cycles,instructions,cache-misses' > results-buffered.meta

不要只比较原始 cycles 数字。通常还应一起查看 instructions、任务耗时和事件是否被缩放或复用；不同 CPU、不同频率策略或不同进程绑定方式下，单个绝对值可能没有独立解释力。输出字段的具体排列以当前系统的 perf 版本为准，脚本要允许解析失败并保留原始文本。

比较前先处理四个可比性边界

Linux 内核文档指出，perf 访问受权限和 perf_event_paranoid 等策略影响；在受限环境中，先记录失败原因并调整授权范围，不能用“少采集到的结果”与完整结果直接对比。生产机器上还应避免把不必要的系统范围采集权限扩大给普通任务。

把一次比较整理成可复用的实验契约

当参数组合超过两组时，建议把每组记录成一行：参数标签、二进制版本、输入数据标识、事件集合、CPU 范围、重复次数、平均值、标准差和采集错误。这样下一次改动只需新增一组记录，不会破坏旧的对照基线。

# 记录实验元数据，方便把硬件计数器和参数组合对应起来
cat > comparison.meta  results-buffered.csv

最后的结论应该回答“在这个输入、这组事件、这台机器和这套重复策略下，哪个参数组合更稳定或更省资源”。如果要把结论推广到其它 CPU、数据规模或并发度，应重新建立对照，而不是把当前计数器当成通用常数。

相关问题

为什么两次 perf stat 的 cycles 差很多？

先检查输入、重复次数、CPU 范围、事件复用和调度噪声，再看参数差异；单次结果不能自动证明程序参数造成了差距。

事件越多，比较结果越完整吗？

不一定。事件过多可能触发 multiplex，导致部分计数器分时采集。对于关键对比，少量稳定事件往往比一条命令塞入大量事件更容易解释。

什么时候需要使用 -A？

当你关心不同 CPU 的独立计数，而不是所有监控 CPU 的合计值时，可以考虑 -A；同时记录 CPU 范围和线程调度方式。

权限失败能不能忽略？

不能。权限失败意味着这组实验没有得到与其它组相同的观测，应该先解决授权或降低采集范围，再重新运行。