使用 perf 查找线程瓶颈并优化 wall-time答案

【问题标题】：Finding threading bottlenecks and optimizing for wall-time with perf使用 perf 查找线程瓶颈并优化 wall-time
【发布时间】：2019-08-03 13:43:36
【问题描述】：

如果核心利用率大致恒定，则使用 perf record 对 CPU 周期进行采样对于查找优化候选者很有用。但是对于具有多个并行性不同的阶段的代码，计算 cpu 周期将强调高度并行的阶段，而不会强调影响 wall-time 的顺序或有限并行阶段。简而言之，幼稚的 perf 使用可能会突出 amdahl's law 的错误分支

所以问题是如何让perf record/perf report 找到优化候选者以减少挂壁时间，这可能是从始终并行代码中最热的循环到中等并行瓶颈到长单线程阶段。

存在不足之处的已知解决方法：

在单核上执行工作负载，以便 wall-time ≅ cpu-cycles
单独分析各个组件

^{meta：这是一个特定于性能的后续to a more general question}

【问题讨论】：

就您提出了五个问题并给出了 1000 个答案而言，今天的问题是一个罕见的事件，不是吗？
如果您的并行程序具有 OpenMP 或 MPI 并行性，并且没有超额订阅且线程绑定到内核（OMP_PROC_BIND，affinity），您可以仅使用主线程分析 cpu 内核（perf record -C 0 ./omp_program或perf report -C 0) - 它将部分移除错误的肢体。第二个想法 - 在主线程和工作线程之间做一个差异（-C 1）。第三个想法：将使用跟踪事件的信号添加到并行库中，并尝试使用--switch-on/--switch-off of perf-report。你能添加例子吗？

标签： linux multithreading performance profiling perf

【解决方案1】：

KDAB Hotspot 是一个 GUI，可以分析 perf record 的输出，如果配置文件已使用 -e sched:sched_switch --switch-events --sample-cpu 记录，还可以显示上下文切换和核心利用率

【讨论】：

不，我认为 cmets 不适合这种故障排除。