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

相关推荐
LinXunFeng6 小时前
Flutter - 使用本地 DevTools 验证 SVG 加载优化
flutter·性能优化·svg
只因在人海中多看了你一眼15 小时前
B.10.01.3-性能优化实战:从JVM到数据库的全链路优化
jvm·数据库·性能优化
嫩萝卜头儿16 小时前
AWT 事件监听器深入浅出:Action/Mouse/Key/Window 全解析与实战
java·开发语言·性能优化
FogLetter16 小时前
解放主线程!Web Worker 让你的前端应用飞起来
前端·性能优化
Hankin_Liu的技术研究室16 小时前
基于 eBPF/BCC的性能调优利器 func_latency:内核/用户函数耗时精准统计,性能专家必备神器!
性能优化
今禾16 小时前
🌐 深入解析 Web Worker:突破 JavaScript 单线程限制
前端·javascript·性能优化
国科安芯1 天前
质子试验:守护芯片安全的关键防线
嵌入式硬件·安全·fpga开发·性能优化·硬件架构
嫩萝卜头儿1 天前
从零掌握 Java AWT:原理、实战与性能优化
java·开发语言·性能优化
嫩萝卜头儿1 天前
深入理解 Java AWT Container:原理、实战与性能优化
java·python·性能优化
Live&&learn1 天前
seo-使用nuxt定义页面标题和meta等信息
vue.js·性能优化