Imr*_*ran 14 c++ profiling intel-vtune callgrind perf
函数在应用程序中花费的总时间可以大致分为两个部分:
通常,剖析器提供函数花费的总时间的估计.是否有可能估算出上述两个组件(Tcomp和Tmem)所花费的时间？
不可能测量这个(并且没有任何意义),因为计算与当前处理器体系结构中的存储器访问重叠.此外,访问存储器通常分解为更多步骤(访问存储器,预取到各种高速缓存级别,实际读取到处理器寄存器).
您可以使用perf及其硬件计数器(如果您的硬件支持)来测量各种缓存级别上的缓存命中和未命中,以估计算法在硬件上的效率.
布伦丹·格雷格（Brendan Gregg）在他最近的博客《CPU利用率错误》中建议在每个周期的PMC中使用指令。简而言之，如果IPC <1.0，则该应用程序可以视为内存绑定。否则，可以将其视为指令绑定。这是他的帖子的相关摘录：
如果您的IPC <1.0，则可能是内存停滞了，软件调整策略包括减少内存I / O并改善CPU缓存和内存局部性，尤其是在NUMA系统上。硬件调优包括使用具有更大CPU缓存，更快的内存，总线和互连的处理器。
如果您的IPC> 1.0，则可能是指令绑定。寻找减少代码执行的方法：消除不必要的工作，缓存操作等。CPU火焰图是进行此研究的好工具。对于硬件调优，请尝试使用更快的时钟速率和更多的内核/超线程。
对于上述规则，我的IPC为1.0。我从哪里得到的？根据我之前在PMC上的工作，我进行了整理。这是获得系统和运行时自定义值的方法：编写两个虚拟工作负载，一个受CPU限制，一个受内存限制。测量其IPC，然后计算其中点。
以下是一些由压力工具及其IPC 生成的虚拟工作负载的示例。
内存绑定测试，IPC为低（0,02）：
$ perf stat stress --vm 4 -t 3
stress: info: [4520] dispatching hogs: 0 cpu, 0 io, 4 vm, 0 hdd
stress: info: [4520] successful run completed in 3s
Performance counter stats for 'stress --vm 4 -t 3':
10767,074968 task-clock:u (msec) # 3,560 CPUs utilized
0 context-switches:u # 0,000 K/sec
0 cpu-migrations:u # 0,000 K/sec
4 555 919 page-faults:u # 0,423 M/sec
4 290 929 426 cycles:u # 0,399 GHz
67 779 143 instructions:u # 0,02 insn per cycle
18 074 114 branches:u # 1,679 M/sec
5 398 branch-misses:u # 0,03% of all branches
3,024851934 seconds time elapsed
CPU绑定测试，IPC为高（1,44）：
$ perf stat stress --cpu 4 -t 3
stress: info: [4465] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: info: [4465] successful run completed in 3s
Performance counter stats for 'stress --cpu 4 -t 3':
11419,683671 task-clock:u (msec) # 3,805 CPUs utilized
0 context-switches:u # 0,000 K/sec
0 cpu-migrations:u # 0,000 K/sec
108 page-faults:u # 0,009 K/sec
30 562 187 954 cycles:u # 2,676 GHz
43 995 290 836 instructions:u # 1,44 insn per cycle
13 043 425 872 branches:u # 1142,188 M/sec
26 312 747 branch-misses:u # 0,20% of all branches
3,001218526 seconds time elapsed