CPU性能优化--性能瓶颈

6.1.3 确定性能瓶颈

假设我们有一个非常小的可以跑8.5 s的基准测试程序,

TMAM

获得

首先,执行程序并采集指定的指标 检测应用程序属于哪个类别。下面是基准测试程序的第一层指标:

~/pmu-tools/toplev.py --core s0-c0 -li -v --no-desc taskset -c 0 ./a.out

S0-C0 Frontend_Bound: 13.81%

S0-C0 Bad_Speculation

S0-C0 backend_bound 53.43%

S0-C0 Retiring:32.53%

  1. S0-C0 Frontend_Bound: 13.81%:这个指标表示CPU的前端(Frontend)部分存在瓶颈,即指令获取和解码阶段不足以喂饱后端执行单元的情况。具体来说,这意味着CPU在这段时间内有一部分比例的周期没有有效地提供足够的指令给后端处理,可能是因为指令缓存未命中、分支预测错误等原因导致的。
  2. S0-C0 Bad_Speculation::这个指标涉及到错误的推测执行,即CPU进行了一些最终不会被执行的指令(uOps),这些指令最终会被丢弃。这通常发生在分支预测错误时,导致CPU执行了一条错误路径上的指令,当实际的分支目标确定后,这些错误路径上的指令就需要被清除,这种清除操作会浪费CPU资源。
  3. S0-C0 Backend_Bound: 53.43%:这个指标表示CPU的后端(Backend)部分存在瓶颈,即执行单元繁忙,等待指令执行完成。这可能是因为内存访问延迟(如缓存未命中)或者执行单元资源竞争导致的。
  4. S0-C0 Retiring: 32.53%:这个指标表示CPU成功执行并退休(Retiring)的指令比例,即这些指令正常完成并可以被后续指令使用。理想情况下,我们希望这个比例尽可能高,因为这表示CPU在高效地执行有用的工作

进程表绑定到了CPU0, ,并且toplev的输出也被限定在这个核上(--core S0-C0)。查看输出,可以发现应用程序的性能时呗CPU后端限定了。现在我们先不去分析它。

往下一层看看

~/pmu-tools/toplev.py --core S0-C0 -l2 -v --no-desc taskset -c 0 ./a.out

//level 1

S0-C0 Frontend_Bound: 13.81%

S0-C0 Bad_Speculation

S0-C0 backend_bound 53.43%

S0-C0 Retiring:32.53%

//level 2

S0-C0 Frontend_Bound.FE_latency 12.11%

S0-C0 Frontend_Bound.FE_Bandwidth 1.84%

S0-C0 Bad_Speculation.Branch_mispred 0.22%

S0-C0 Bad_Speculation_Machine.Clear 0.01%

S0-C0 Backend_Bound.Memory_Bound 44.59%

S0-C0 Backend_Bound.Core_Bound 8.6%

S0-C0 Retiring.Base 24.83%

S0-C0 Retring_Microcode_Sequencer 7.66%

我们发现基准测试程序的性能被内存访问限定了,几乎有一半的CPU运行资源都被浪费在了等待内存请求完成上,我们继续下钻一层。

~/pmu-tools/toplev.py --core S0-C0 -l3 -v --no-desc taskset -c 0 ./a.out

S0-C0 BE_Bound.Mem_Bound.L1_Bound 4.39%

S0-C0 BE_Bound.Mem_Bound.L2_Bound 2.42%

S0-C0 BE_Bound.Mem_Bound.L3_Bound 5.75%

S0-C0 BE_Bound.Mem_Bound.DRAM_Bound 47.11%

S0-C0 BE_Bound.Mem_Bound.Store_Bound 0.69%

S0-C0 BE_Bound.Core_Bound.Divider_Bound 6.56% 除法运算

S0-C0 BE_Bound.Core_Bound.Porte_Util 11.31%

我们发现性能瓶颈在DRAM_Bound,这告诉我们很多内存访问在所有层级的缓存中都没有命中,并且最终走到了主存。如果采集了基准测试程序的全部L3缓存未命中的绝对数量,我们也可以通过它来确认,对于Skylake CPU架构,DRAM_Bound指标时通过CYCLE_ACTIVITY.STALLS_L3_MISS性能事件统计的

我们可以通过下面代码采集

perf stat -e cycle.cycle_activity.stalls_l3_miss -- ./a.out

相关推荐
爱喝水的鱼丶6 小时前
SAP-ABAP:性能优化效果验证与回归测试:优化前后性能对比、业务逻辑兼容性校验方案
性能优化·sap·abap·回归测试·开发交流·交流学习
starzhang9 小时前
06 从 Trace 看 Android 启动流程
性能优化
工业设备方案笔记9 小时前
RK3588 AI设备性能优化指南:如何释放ARM边缘计算平台真正性能?
arm开发·人工智能·目标跟踪·性能优化·架构·边缘计算
数据库小学妹11 小时前
空间数据库查询慢怎么排查?索引失效、表膨胀、SQL优化实战(附排查命令)
数据库·性能优化·信创·故障排查·索引调优·空间数据库
爱喝水的鱼丶1 天前
SAP-ABAP:接口与报表场景专项优化:RFC/ODATA 接口、ALV 报表的性能提升方案
运维·性能优化·接口·sap·abap·rfc·经验交流
这个DBA有点耶1 天前
数据库管理系统选型:从关系型到NewSQL的架构演进与决策框架
数据库·mysql·云原生·性能优化·架构·dba
灯澜忆梦1 天前
【MySQL11】进阶篇 | 索引_#3使用规则
数据库·sql·mysql·性能优化
starzhang1 天前
05 从 Perfetto 看懂 Binder 调用链
性能优化
大龄秃头程序员1 天前
一次关于 LRUCache 的工程化落地:从数据结构到 Feed 图片缓存实践
性能优化
jeffwang1 天前
我把同一个压测做错了三次,第四次才发现真正的瓶颈
分布式·性能优化·rust