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

相关推荐
UWA2 小时前
有什么指标可以判断手机是否降频
人工智能·智能手机·性能优化·memory·游戏开发
鼠鼠我捏,要死了捏3 小时前
深入解析Java GC调优:从原理到实战
java·性能优化·gc调优
武子康14 小时前
Java-154 深入浅出 MongoDB 用Java访问 MongoDB 数据库 从环境搭建到CRUD完整示例
java·数据库·分布式·sql·mongodb·性能优化·nosql
性感博主在线瞎搞15 小时前
【人工智能】神经网络的优化器optimizer(四):Adam自适应动量优化器
人工智能·深度学习·神经网络·性能优化·优化器
鼠鼠我捏,要死了捏17 小时前
深入剖析Java垃圾回收性能优化实战指南
java·性能优化·gc
码界奇点19 小时前
MongoDB 排序操作详解sort方法使用指南
数据库·mongodb·性能优化
武子康19 小时前
Java-157 MongoDB 存储引擎 WiredTiger vs InMemory:何时用、怎么配、如何验证 mongod.conf
java·数据库·sql·mongodb·性能优化·系统架构·nosql
白帽子凯哥哥20 小时前
SpringBoot + Elasticsearch实战:从零构建高性能搜索与数据分析平台
大数据·spring boot·后端·elasticsearch·搜索引擎·性能优化·聚合查询
马拉萨的春天20 小时前
block的样式有哪些?如果copy的话分别会有啥样式
flutter·性能优化·ios的block
DemonAvenger1 天前
深入Redis String:从基础到实战,10年经验的后端工程师带你解锁最佳实践
数据库·redis·性能优化