关于c++:CC-性能优化背后的方法论TMAM

开发过程中咱们多少都会关注服务的性能，然而性能优化是绝对比拟艰难，往往须要多轮优化、测试，属于费时费力，有时候还未必有好的成果。然而如果有较好的性能优化办法领导、工具辅助剖析能够帮忙咱们疾速发现性能瓶颈所在，针对性地进行优化，能够事倍功半。

性能优化的难点在于找出要害的性能瓶颈点，如果不借助一些工具辅助定位这些瓶颈是十分艰难的，例如：c++ 程序通常大家可能都会借助 perf /bcc 这些工具来寻找存在性能瓶颈的中央。性能呈现瓶颈的起因很多比方 CPU、内存、磁盘、架构等。本文就仅仅是针对 CPU 调优进行调优，即如何榨干 CPU 的性能，将 CPU 吞吐最大化。（实际上 CPU 出厂的时候就曾经决定了它的性能，咱们须要做的就是让 CPU 尽可能做有用功），所以针对 CPU 利用率优化，实际上就是找出咱们写的不够好的代码进行优化。

先敬上代码：

#include <stdlib.h>
 
 #define CACHE_LINE __attribute__((aligned(64)))
 
 struct S1
 {
   int r1;
   int r2;
   int r3;
   S1 ():r1 (1), r2 (2), r3 (3){}} CACHE_LINE;
 void add(const S1 smember[],int members,long &total) {
     int idx = members;
     do {total += smember[idx].r1;
        total += smember[idx].r2;
        total += smember[idx].r3;
     }while(--idx);
 }
 int main (int argc, char *argv[]) {
   const int SIZE = 204800;
   S1 *smember = (S1 *) malloc (sizeof (S1) * SIZE);
   long total = 0L;
   int loop = 10000;
   while (--loop) {  // 不便比照测试
       add(smember,SIZE,total);
   }
   return 0;
 }

注：代码逻辑比较简单就是做一个累加操作，仅仅是为了演示。

编译 + 运行：

g++ cache_line.cpp -o cache_line ; task_set -c 1 ./cache_line

下图是示例 cache\_line 在 CPU 1 外围上运行，CPU 利用率达到 99.7%，此时 CPU 基本上是满载的，那么咱们如何晓得这个 cpu 运行 cache\_line 服务过程中是否做的都是有用功，是否还有优化空间？

有的同学可能说，能够用 perf 进行剖析寻找热点函数。的确是能够应用 perf，然而 perf 只能晓得某个函数是热点（或者是某些汇编指令），然而没法确认引起热点的是 CPU 中的哪些操作存在瓶颈，比方取指令、解码、…..

如果你还在为判断是 CPU 哪些操作导致服务性能瓶颈而手足无措，那么这篇文章将会你给你授道解惑。本文次要通过介绍自顶向下分析方法（TMAM）方法论来疾速、精准定位 CPU 性能瓶颈以及相干的优化倡议，帮忙大家晋升服务性能。为了让大家更好的了解本文介绍的办法，须要筹备些常识。

(图片起源：intel 官网文档)

古代的计算机个别都是冯诺依曼计算机模型都有 5 个外围的组件：运算、存储、管制、输出、输入。本文介绍的办法与 CPU 无关，CPU 执行过程中波及到取指令、解码、执行、回写这几个最根底的阶段。最早的 CPU 执行过程中是一个指令依照以上步骤顺次执行完之后，能力轮到第二条指令即指令串行执行，很显然这种形式对 CPU 各个硬件单元利用率是非常低的，为了进步 CPU 的性能，Intel 引入了多级流水、乱序执行等技术晋升性能。个别 intel cpu 是 5 级流水线，也就是同一个 cycle 能够解决 5 个不同操作，一些新型 CPU 中流水线多达 15 级，下图展现了一个 5 级流水线的状态，在 7 个 CPU 指令周期中指令 1，2，3 曾经执行实现，而指令 4，5 也在执行中，这也是为什么 CPU 要进行指令解码的目标：将指令操作不同资源的操作分解成不同的微指令（uops），比方 ADD eax,[mem1] 就能够解码成两条微指令，一条是从内存 [mem1] 加载数据到长期寄存器, 另外一条就是执行运算，这样就能够在加载数据的时候运算单元能够执行另外一条指令的运算 uops，多个不同的资源单元能够并行工作。

(图片起源：intel 官网文档)

CPU 外部还有很多种资源比方 TLB、ALU、L1Cache、register、port、BTB 等而且各个资源的执行速度各不相同，有的速度快、有的速度慢，彼此之间又存在依赖关系，因而在程序运行过程中 CPU 不同的资源会呈现各种各样的束缚，本文使用 TMAM 更加主观的剖析程序运行过程中哪些外在 CPU 资源呈现瓶颈。

TMAM 即 Top-down Micro-architecture Analysis Methodology 自顶向下的微架构分析方法。这是 Intel CPU 工程师演绎总结用于优化 CPU 性能的方法论。TMAM 实践根底就是将各类 CPU 各类微指令进行归类从大的方面先确认可能呈现的瓶颈，再进一步下钻剖析找到瓶颈点，该办法也合乎咱们人类的思维，从宏观再到细节，过早的关注细节，往往须要破费更多的工夫。这套方法论的劣势在于：

即便没有硬件相干的常识也可能基于 CPU 的个性优化程序
系统性的打消咱们对程序性能瓶颈的猜想：分支预测成功率低？CPU 缓存命中率低？内存瓶颈？
疾速的辨认出在多核乱序 CPU 中瓶颈点

TMAM 评估各个指标过程中采纳两种度量形式一种是 cpu 时钟周期(cycle[6])，另外一种是 CPU pipeline slot[4]。该办法中假设每个 CPU 内核每个周期 pipeline 都是 4 个 slot 即 CPU 流水线宽是 4。下图展现了各个时钟周期四个 slot 的不同状态，留神只有 Clockticks 4，cycle 利用率才是 100%，其余的都是 cycle stall（进展、气泡）。

(图片起源：intel 官网文档)

（图片来源于：intel 文档）

TMAM 将各种 CPU 资源进行分类，通过不同的分类来辨认应用这些资源的过程中存在瓶颈，先从大的方向确认大抵的瓶颈所在，而后再进行深入分析，找到对应的瓶颈点各个击破。在 TMAM 中最顶层将 CPU 的资源操作分为四大类，接下来介绍下这几类的含意。

Retiring 示意运行无效的 uOps 的 pipeline slot，即这些 uOps[3]最终会退出（留神一个微指令最终后果要么被抛弃、要么退出将后果回写到 register），它能够用于评估程序对 CPU 的绝对比拟实在的有效率。现实状况下，所有流水线 slot 都应该是 ”Retiring”。100% 的 Retiring 意味着每个周期的 uOps Retiring 数将达到最大化，极致的 Retiring 能够减少每个周期的指令吞吐数（IPC）。须要留神的是，Retiring 这一分类的占比高并不意味着没有优化的空间。例如 retiring 中 Microcode assists 的类别实际上是对性能有损耗的，咱们须要防止这类操作。

Bad Speculation 示意谬误预测导致节约 pipeline 资源，包含因为提交最终不会 retired 的 uOps 以及局部 slots 是因为从先前的谬误预测中复原而被阻塞的。因为预测谬误分支而节约的工作被归类为 ” 谬误预测 ” 类别。例如：if、switch、while、for 等都可能会产生 bad speculation。

Front-End 职责：

取指令

将指令进行解码成微指令

将指令分发给 Back-End，每个周期最多散发 4 条微指令

Front-End Bound 示意解决其的 Front-End 的一部分 slots 没法交付足够的指令给 Back-End。Front-End 作为处理器的第一个局部其外围职责就是获取 Back-End 所需的指令。在 Front-End 中由预测器预测下一个须要获取的地址，而后从内存子系统中获取对应的缓存行，在转换成对应的指令，最初解码成 uOps（微指令）。Front-End Bound 意味着，会导致局部 slot 即便 Back-End 没有阻塞也会被闲置。例如因为指令 cache misses 引起的阻塞是能够归类为 Front-End Bound。内存排序

Back-End 的职责：

接管 Front-End 提交的微指令

必要时对 Front-End 提交的微指令进行重排

从内存中获取对应的指令操作数

执行微指令、提交后果到内存

Back-End Bound 示意局部 pipeline slots 因为 Back-End 短少一些必要的资源导致没有 uOps 交付给 Back-End。

Back-End 处理器的外围局部是通过调度器乱序地将筹备好的 uOps 分发给对应执行单元，一旦执行实现，uOps 将会依据程序的程序返回对应的后果。例如：像 cache-misses 引起的阻塞（进展）或者因为除法运算器过载引起的进展都能够归为此类。此类别能够在进行细分为两大类：Memory-Bound、Core Bound。

演绎总结一下就是：

Front End Bound = Bound in Instruction Fetch -> Decode (Instruction Cache, ITLB)

Back End Bound = Bound in Execute -> Commit (Example = Execute, load latency)

Bad Speculation = When pipeline incorrectly predicts execution (Example branch mispredict memory ordering nuke)

Retiring = Pipeline is retiring uops

一个微指令状态能够依照下图决策树进行归类：

（图片起源：intel 官网文档）

上图中的叶子节点，程序运行肯定工夫之后各个类别都会有一个 pipeline slot 的占比，只有 Retiring 的才是咱们所冀望的后果，那么每个类别占比应该是多少才是正当或者说性能相对来说是比拟好，没有必要再持续优化？intel 在实验室里依据不同的程序类型提供了一个参考的规范：

（图片起源：intel 用户手册）

只有 Retiring 类别是越高越好，其余三类都是占比越低越好。如果某一个类别占比比较突出，那么它就是咱们进行优化时重点关注的对象。

目前有两个支流的性能剖析工具是基于该方法论进行剖析的：Intel vtune（免费而且还老贵~），另外一个是开源社区的 pm-tools。

有了下面的一些常识之后咱们在来看下开始的示例的各分类状况：

尽管各项指标都在后面的参照表的范畴之内，然而只有 retiring 没有达到 100% 都还是有可优化空间的。上图中显然瓶颈在 Back-End。

应用 Vtune 或者 pm-tools 工具时咱们应该关注的是除了 retired 之外的其余三个大分类中占比比拟高，针对这些较为突出的进行剖析优化。另外应用工具剖析工程中须要关注 MUX Reliability（多元分析可靠性）这个指标，它越靠近 1 示意以后后果可靠性越高，如果低于 0.7 示意以后剖析后果不牢靠，那么倡议加长程序运行工夫以便采集足够的数据进行剖析。上面咱们来针对三大分类进行剖析优化。

（图片起源：intel 官网文档）

上图中展现了 Front-End 的职责即取指令（可能会依据预测提前取指令）、解码、分发给后端 pipeline，它的性能受限于两个方面一个是 latency、bandwidth。对于 latency，个别就是取指令（比方 L1 ICache、iTLB 未命中或解释型编程语言 python\java 等）、decoding（一些非凡指令或者排队问题）导致提早。当 Front-End 受限了，pipeline 利用率就会升高，下图非绿色局部示意 slot 没有被应用，ClockTicks 1 的 slot 利用率只有 50%。对于 BandWidth 将它划分成了 MITE，DSB 和 LSD 三个子类，感兴趣的同学能够通过其余路径理解下这三个子分类。

（图片起源：intel 官网文档）

代码尽可能减少代码的 footprint7：

C/C++ 能够利用编译器的优化选项来帮忙优化，比方 GCC -O* 都会对 footprint 进行优化或者通过指定 -fomit-frame-pointer 也能够达到成果；

充分利用 CPU 硬件个性：宏交融（macro-fusion)

宏交融个性能够将 2 条指令合并成一条微指令，它能晋升 Front-End 的吞吐。示例：像咱们通常用到的循环：

所以倡议循环条件中的类型采纳无符号的数据类型能够应用到宏交融个性晋升 Front-End 吞吐量。

调整代码布局（co-locating-hot-code)：

①充分利用编译器的 PGO 个性：-fprofile-generate -fprofile-use

②能够通过 \_\_attribute\_\_ ((hot)) \_\_attribute\_\_ ((code)) 来调整代码在内存中的布局,hot 的代码

在解码阶段有利于 CPU 进行预取。

其余优化选项，能够参考：GCC 优化选项 GCC 通用属性选项

分支预测优化

① 打消分支能够缩小预测的可能性能：比方小的循环能够开展比方循环次数小于 64 次（能够应用 GCC 选项 -funroll-loops)

② 尽量用 if 代替:? , 不倡议应用 a =b>0? x:y 因为这个是没法做分支预测的

③ 尽可能减少组合条件，应用繁多条件比方：if(a||b) {}else{} 这种代码 CPU 没法做分支预测的

④对于多 case 的 switch，尽可能将最可能执行的 case 放在最后面

⑤ 咱们能够依据其动态预测算法投其所好，调整代码布局，满足以下条件：

前置条件，使条件分支后的的第一个代码块是最有可能被执行的

bool  is_expect = true;
 if(is_expect) {// 被执行的概率高代码尽可能放在这里} else {// 被执行的概率低代码尽可能放在这里}
后置条件，使条件分支的具备向后指标的分支不太可能的指标
 
 do {// 这里的代码尽可能减少运行} while(conditions);

这一类别的优化波及到 CPU Cache 的应用优化,CPU cache[14]它的存在就是为了补救超高速的 CPU 与 DRAM 之间的速度差距。CPU 中存在多级 cache（register\L1\L2\L3），另外为了减速 virtual memory address 与 physical address 之间转换引入了 TLB。

如果没有 cache，每次都到 DRAM 中加载指令，那这个提早是没法承受的。

（图片起源：intel 官网文档）

调整算法缩小数据存储，缩小前后指令数据的依赖进步指令运行的并发度
依据 cache line 调整数据结构的大小
防止 L2、L3 cache 伪共享

（1）正当应用缓存行对齐

CPU 的缓存是弥足珍贵的，应该尽量的进步其使用率，平时应用过程中可能存在一些误区导致 CPU cache 无效利用率比拟低。上面来看一个不适宜进行缓存行对齐的例子：

#include <stdlib.h>
 #define CACHE_LINE
 
 struct S1
 {
   int r1;
   int r2;
   int r3;
   S1 ():r1 (1), r2 (2), r3 (3){}} CACHE_LINE;
 
 int main (int argc, char *argv[])
{// 与后面统一}

上面这个是测试成果：

做了缓存行对齐：

#include <string.h>
  #include <stdio.h>
 
  #define CACHE_LINE __attribute__((aligned(64)))
 
  struct S1 {
    int r1;
    int r2;
    int r3;
    S1(): r1(1),r2(2),r3(3){}} CACHE_LINE;
 
  int main(int argc,char* argv[]) {// 与后面统一}

测试后果:

通过比照两个 retiring 就晓得，这种场景下没有做 cache 对齐缓存利用率高，因为在单线程中采纳了缓存行导致 cpu cache 利用率低，在下面的例子中缓存行利用率才 3 *4/64 = 18%。缓存行对齐应用准则：

多个线程存在同时写一个对象、构造体的场景（即存在伪共享的场景）
对象、构造体过大的时候
将高频拜访的对象属性尽可能的放在对象、构造体首部

（2）伪共享

后面次要是缓存行误用的场景，这里介绍下如何利用缓存行解决 SMP 体系下的伪共享（false shared)。多个 CPU 同时对同一个缓存行的数据进行批改，导致 CPU cache 的数据不统一也就是缓存生效问题。为什么伪共享只产生在多线程的场景，而多过程的场景不会有问题？这是因为 linux 虚拟内存的个性，各个过程的虚拟地址空间是互相隔离的，也就是说在数据不进行缓存行对齐的状况下，CPU 执行过程 1 时加载的一个缓存行的数据，只会属于过程 1，而不会存在一部分是过程 1、另外一部分是过程 2。

（上图中不同型号的 L2 cache 组织模式可能不同，有的可能是每个 core 独占例如 skylake）

伪共享之所以对性能影响很大，是因为他会导致本来能够并行执行的操作，变成了并发执行。这是高性能服务不能承受的，所以咱们须要对齐进行优化，办法就是 CPU 缓存行对齐（cache line align)解决伪共享, 原本就是一个以空间换取工夫的计划。比方下面的代码片段：


#define CACHE_LINE __attribute__((aligned(64)))
 
  struct S1 {
    int r1;
    int r2;
    int r3;
    S1(): r1(1),r2(2),r3(3){}} CACHE_LINE;

所以对于缓存行的应用须要依据本人的理论代码区别对待，而不是随声附和。

(图片起源：intel 官网文档)

当 Back-End 删除了微指令，就呈现 Bad Speculation，这意味着 Front-End 对这些指令所作的取指令、解码都是无用功，所以为什么说开发过程中应该尽可能的避免出现分支或者应该晋升分支预测准确度可能晋升服务的性能。尽管 CPU 有 BTB 记录历史预测状况，然而这部分 cache 是十分稀缺，它能缓存的数据十分无限。

分支预测在 Font-End 中用于减速 CPU 获取指定的过程，而不是等到须要读取指令的时候才从主存中读取指令。Front-End 能够利用分支预测提前将须要预测指令加载到 L2 Cache 中，这样 CPU 取指令的时候提早就极大减小了，所以这种提前加载指令时存在误判的状况的，所以咱们应该防止这种状况的产生，c++ 罕用的办法就是：

在应用 if 的中央尽可能应用 gcc 的内置分支预测个性(其余状况能够参考 Front-End 章节)

#define likely(x) __builtin_expect(!!(x), 1) //gcc 内置函数, 帮忙编译器分支优化
 #define unlikely(x) __builtin_expect(!!(x), 0)
 
 if(likely(condition)) {// 这里的代码执行的概率比拟高}
 if(unlikely(condition)) {// 这里的代码执行的概率比拟高}
 
 // 尽量避免远调用

防止间接跳转或者调用

在 c ++ 中比方 switch、函数指针或者虚函数在生成汇编语言的时候都可能存在多个跳转指标，这个也是会影响分支预测的后果，尽管 BTB 可改善这些然而毕竟 BTB 的资源是很无限的。（intel P3 的 BTB 512 entry，一些较新的 CPU 没法找到相干的数据）

这里咱们再看下最开始的例子，采纳下面提到的优化办法优化完之后的评测成果如下：

g++ cache\_line.cpp -o cache\_line -fomit-frame-pointer; task\_set -c 1 ./cache\_line

耗时从原来的 15s 升高到当初 9.8s，性能晋升 34%：retiring 从 66.9% 晋升到 78.2%；Back-End bound 从 31.4% 升高到 21.1%

[1] CPI（cycle per instruction) 均匀每条指令的均匀时钟周期个数

[2] IPC（instruction per cycle）每个 CPU 周期的指令吞吐数

[3] uOps 古代处理器每个时钟周期至多能够译码 4 条指令。译码过程产生很多小片的操作，被称作微指令(micro-ops, uOps)

[4] pipeline slot pipeline slot 示意用于解决 uOps 所须要的硬件资源，TMAM 中假设每个 CPU core 在每个时钟周期中都有多个可用的流水线插槽。流水线的数量称为流水线宽度。

[5] MIPS(MillionInstructions Per Second) 即每秒执行百万条指令数 MIPS= 1/（CPI×时钟周期）= 主频 /CPI

[6]cycle 时钟周期：cycle=1/ 主频

[7] memory footprint 程序运行过程中所须要的内存大小. 包含代码段、数据段、堆、调用栈还包含用于存储一些暗藏的数据比方符号表、调试的数据结构、关上的文件、映射到过程空间的共享库等。

[8] MITE Micro-instruction Translation Engine

[9]DSB Decode stream Buffer 即 decoded uop cache

[10]LSD Loop Stream Detector

[11] 各个 CPU 维度剖析

[12] TMAM 实践介绍

[13] CPU Cache

[14] 微架构

作者：vivo- Li Qingxing

关于c++:CC-性能优化背后的方法论TMAM

一、示例

二、CPU 流水线介绍

三、自顶向下剖析（TMAM）

3.1 根底分类

3.1.1 Retiring

3.1.2 Bad Speculation

3.1.3 Front-End-Boun

3.1.4 Back-End-Bound

3.3 如何针对不同类别进行优化？

3.3.1 Front-End Bound

3.3.1.1 于 Front-End 的优化倡议：

3.3.2 Back-End Bound

3.3.2.1 优化倡议：

3.3.3 Bad Speculation 分支预测

四、写在最初

五、CPU 常识充电站