深入理解计算机系统_第五章_优化程序性能

约定不等于承诺〃 2022-02-01 12:57 410阅读 0赞

# 检讨 #

在公司就有同事给我指出过：“大段贴代码的技术博客都是垃圾”，如今反复的体味到这句话很对。技术博客确实应该保持篇幅适中，思路流畅简洁，我最近在看自己写的深入理解计算机系统系列文章，真是又长又臭，第三章和第四张我自己都看不下去，基本是在摘抄原文中的话，那人家干嘛看我这博客，人家自己买本书不好的多？在我这里转一手，除了排版更垃圾没其他改变了，真是让人失望透顶了。接下来我写博客，一定要多加自己的理解，多画结构图，帮助自己和别人理清脉络。

# 章前导读 #

写程序一定要在保证运行正确的基础上尽可能运行的快，并且代码要清晰简洁，这样在日后需要修改代码时，其他人能够读懂和理解代码。  
编写高效程序需要做到三点：1.必须选择一组适当的算法和数据结构；2.必须编写出编译器能够有效优化以转换成高效可执行代码的源代码（对于这一点，理解优化编译器的能力和局限性很重要）；3.将一个任务分成多个部分，这些部分可以在多核和多处理器的某种组合上并行计算。对于优化程序的一个挑战就是尽管做了大量的变化，但还是要尽量维护代码的简洁和可读性。  
程序优化的第一步就是消除不必要的工作，让代码尽可能有效地执行所期望的任务。包括不必要的函数调用、条件测试和内存引用。  
为了使程序性能最大化，程序员和编译器都需要知道一个模型，用来指明目标机器如何处理指令，以及各个操作的时序特性（比如知道了时序信息，就能确定是用一条乘法还是用移位和加法的组合）。文中给出了一种`图形数据流`表示法（基于Intel和AMD处理器），可以使处理器对指令的执行形象化，可以利用它预测程序的性能。  
了解处理器运作后，可以进行程序优化的第二步，利用处理器提供的`指令级并行`能力，同时执行多条指令。比如降低一个程序不同部分的数据相关程度，增加并行度，这样就可以同时执行这些部分了。  
最后本章还介绍了`代码剖析程序`，该程序是测量程序各个部分性能的工具。可以帮助找到代码中低效率的地方，进而确定应该着重优化的部分。  
研究程序的汇编代码表示是理解编译器以及产生的代码会如何运行的最有效手段之一。我们常常通过确认关键路径来确定执行一个循环所需要的时间。关键路径就是在循环中形成的数据相关链，然后回过头来修改源代码。

# 优化编译器的能力和局限性 #

GCC可以通过“-o1”、“-o2”、“-o3”来控制优化级别，更大的数字代表更大量的优化，这样可以更好的提高性能，但也会让程序规模变大，也更难以用标准的调试工具进行调试。

如果一个程序中有可能出现`内存别名使用`的情况（`内存别名使用`是指两个指针可能指向同一个内存位置），编译器对其优化的能力就大大减少了，因为这两个指针如果指向同一个内存，其结果与指向不同内存的结果大不相同，这就是一个妨碍优化的因素。如果编译器不能确定两个指针是够指向同一位置，就必须假设什么情况都可能，这就限制了可能的优化策略。

第二个妨碍优化的因素是函数调用，比如func1返回了f()+f()+f()+f()，func2返回4\*f()，看起来返回的结果应该是一样，但func1调用了4次，func2只调用了1次，看起来func2的效率更高。  
但如果f()中改变了某一个全局数据，例如f()的函数主体是 return counter++（这个counter被定义为全局变量，初始化为0），那调用func1之后，counter = 0 + 1 + 2 + 3 = 6，而调用func2后，counter = 0。  
也就是说，如果被调用的函数有一个副作用——修改了全局程序状态的一部分（这个例子中是一个全局变量），那改变调用它的次数就会改变程序的行为。  
编译器不会去判断一个函数有没有上述的副作用，而是默认最糟糕的情况，保持所有的函数调用不变。  
tips：有时编译器会利用内联函数替换对包含函数调用的代码进行优化（内联函数替换就是将函数主体替换到调用处），这样就不存在上述的问题了，因为函数主体被直接替换了过来，不过要对函数进行追踪或者设置断点，或者用代码剖析的方式评估程序性能的话，就不应该使用内联函数替换了。

# 表示程序性能 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70]  
上述的两个函数psum1和psum2最终的效果是一样的，当把两个函数需要的时间和n的取值范围做一个最小二乘拟合后，发现前者近似于368 + 9n，后者近似于368 + 6n。式子中n的系数成为`每元素周期数（CPE）`的有效值，所以我们在优化程序时，会集中精力于减小CPE。根据这种量度标准，psum2的CPE为6，优于CPE为9.0的pusm1。

# 程序示例 #

文中设计了一个程序，用来比较优化后与优化前的的CPE。程序如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 1]  
其中当OP为+时，IDENT初始化为0；OP为\*时，IDENT初始化为1，vec\_lenget函数计算出数据结构中数据部分的长度，get\_vec\_element函数最终会把结构体v中的第i个数据地址赋值给val。整个函数通过宏定义，实现了对一个数据结构中所有数据的加和或乘积。  
![在这里插入图片描述][20190514153029926.png]  
图中分别针对整数加法、乘法和浮点数加法、乘法比较了优化前后的CPE。

# 消除循环的低效率 #

上面的combine1函数，在for循环中调用了vec\_length函数，每循环一次都需要调用该函数一次，但是调用结果又不会随着循环进行而改变，因此只需要计算一次长度，此后直接用这个长度就可以了。修改如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 2]  
测试结果如下：  
![在这里插入图片描述][2019051415441648.png]这种优化称为`代码移动`。这类优化包括识别要执行多次但计算结果不会改变的计算。代码移动前，往往程序会在小数据集上测试，这时候看不出什么端倪，可当数据集变成100万后，这段代码就完完全全变成了危险炸弹。所以一定要避免引入这样的渐近低效率。

# 减少过程调用 #

过程调用会有很大开销，而且妨碍优化。过程调用就像是combine2代码中，每次循环迭代都会调用get\_vec\_element来获取下一个向量元素，而该函数中，每次都要把向量索引i与循环边界作比较，这就很明显的造成了低效率。  
为了减少过程调用，直接用结构体的起始地址操作。一方面这种改变严重损害了程序的模块性和安全性，从原则上说，该结构体的使用者甚至不应该知道结构体的内容是作为数据来存储的，而不是作为诸如链表之类的某种其他数据结构来存储的；另一方面这种变化是获得高性能结果的必要步骤。  
![在这里插入图片描述][20190515084911360.png]  
性能没有明显提升，显然还有其他限制性更大的操作在起作用。

# 消除不必要的内存引用 #

回顾combine2函数的代码，在每次循环中都用到了语句 \*dest = \*dest OP data\[i\]，这就意味着每次循环，都要从&dest中读出数值，再写回&dest，这样的读写很浪费，因为每一次循环从&dest读出的值就是上次循环最后写入的值。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 3]  
为了消除这种不必要的内存读写，如上更改代码，用一个临时变量acc循环积累计算出来的值，循环结束后再放入&dest中。  
![在这里插入图片描述][20190515085909740.png]  
可以看到程序性能有了显著提高。  
那么为什么编译器不自动的把combine3函数转换成combine4函数呢？其实由于内存别名使用，两个函数可能会有不一样的行为。  
例如，设v = \[2，3，5\]是一个3元素组成的数据结构，考虑下面两种函数调用：  
![在这里插入图片描述][20190515090808693.png]  
也就是在向量最后一个元素和存放结果的目标之间创建一个别名，函数的执行如下：  
![在这里插入图片描述][20190515090822824.png]  
正因为编译器有如上的考虑，所以在编译combine3的时候，不会优化为形如combine4的代码。

# 理解现代处理器 #

之前的优化都是降低了过程调用、和一些妨碍优化的因素。想再进一步提高性能，必须考虑利用处理器`微体系结构`的优化，也就是处理器用来执行指令的底层系统设计。  
为了理解改进性能的方法，我们需要理解现代处理器的微体系结构。现在微处理器采用复杂而奇异的微处理器结构，其中，多条指令可以并行地执行（指令级并行），同时又呈现出一种简单的顺序执行指令的表象。  
对于微处理器系统的原则有一般性了解就能够理解如何实现指令级并行了，其中有两种下届描述了程序的最大性能。当一系列操作必须按照严格顺序执行时，就会遇到`延迟界限`，因为下一条指令开始之前，这条指令必须结束。当代码中的数据相关限制了处理器利用指令级并行的能力时，延迟界限能够限制程序性能。`吞吐量界限`刻画了处理器功能单元的原始计算能力。这个界限是程序性能的终极限制。

## 整体操作 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 4]  
这是一个现代微处理器的简化示意图，这些处理器成为`超标量`，即可以在每个时钟周期执行多个操作，而且是`乱序的`，即指令执行顺序不一定与它们在机器级程序中的顺序一致。  
整个设计有两部分：指令控制单元（ICU），和执行单元（EU）。前者负责从内存中读出指令序列，并根据这些指令序列生成一组针对程序数据的基本操作；后者执行这些操作。（乱序处理器比按序处理器相比更复杂，但也能更好的进行指令级并行）  
ICU从`指令高速缓冲`中读取指令（一个特殊告诉存储器，包含最近访问的指令）。ICU把指令在执行之前就取出进行译码，在遇到分支时，会利用`分支预测`技术猜测选择哪个分支及其目标地址，再利用`投机执行`技术取出预测的目标地址指令，在还不确定分支预测是否正确之前就开始执行这些指令，如果之后确定分支预测是错误的，再回到之前的状态，取另一个方向的指令执行，标记为`取指控制`的块包括分支预测，以完成确定哪些指令的任务。  
`指令译码`逻辑接受实际的程序指令，并将它们转换成基本操作，比如两个数相加、向内存写数据等。对于x86机器，一条指令可能会译码为多个操作。  
EU接受来自取指单元的操作。通常每个时钟周期会接受多个操作。这些操作会被分派到`功能单元`中，它们会执行实际操作。  
读写内存是由加载和存储单元实现的。加载单元和存储单元都分别有一个加法器来完成地址计算。图中加载和存储单元通过`数据告诉缓存`来访问内存。数据高速缓存是一个高速存储器，存放着最近访问的数据值。  
使用投机执行记住对操作求值，但是结果不会存放在程序寄存器或数据内存中，除非处理器能确定应该执行这些指令。分支操作送给EU，不是确定分支该往哪里去，而是确定分支预测是否正确，如果预测错误，EU就丢弃之前计算的结果，还告知分支单元预测错了，指出正确的分支目的，然后分支单元开始新的取指。这种`预测错误`会导致很大的性能开销。  
在ICU中，`退役单元`记录正在进行的处理，并确保它遵守机器级程序的顺序语义。指令译码时，关于指令的信息被放置在一个先进先出的队列中，这个信息会一直保持在队列，直到发生以下两个结果之一：1.一旦一条指令的操作完成了，而且所有引起这条指令的分支点也都被确认预测正确了，那这条指令就可以`退役`了，所有读程序寄存器的更新都可以被实际执行了。2.如果引起该指令的某个分支点预测错误，这条指令会被`清空`，丢弃计算结果。  
控制操作数在执行单元间传送的最常见的机制称为`寄存器重命名`。当一条更新寄存器r的指令译码时，产生标记t，得到一个指向该操作结果的唯一的标识符。条目（r，t）被加入到一张表中，该表维护着每个程序寄存器r与会更新该寄存器的操作的标记t之间的关联。当随后以寄存器r作为操作数的指令译码时，发送到执行单元的操作会包含t作为操作数源的值。当某个执行单元完成第一个操作时，会生成一个结果（v，t），指明标记为t的操作产生值v。所有等待t作为源的操作都能使用v作为源值，这就是一种形式的数据转发。通过这种机制，值可以从一个操作直接转发到另一个操作，而不是写到寄存器文件再读出来，使得第二个操作能够在第一个操作完成后尽快开始。

## 功能单元的性能 ##

在描述性能时一以下数值来刻画：`延迟`：完成运算所需要的总时间；`发射时间`：表示两个连续的同类型的运算之间需要的最小时钟周期数；`容量`：表示能够执行该运算的功能单元的数量。  
发射时间为1的功能单元被称为`完全流水线化的`：每个时钟周期可以开始一个新的运算。表达发射时间的一种更常见的方法是指明这个功能单元的最大`吞吐量`，定义为发射时间的倒数。一个完全流水线化的功能单元有最大的吞吐量，每个时钟周期一个运算，而发射时间较大的功能单元的最大吞吐量比较小。  
这些算术运算的延迟、发射时间和容量会影响合并函数的性能。我们用CPE值的几个基本界限来描述这种影响：  
![在这里插入图片描述][2019051511534380.png]  
`延迟界限`给出了任何必须严格顺序完成合并运算的函数所需要的最小CPE值。根据功能单元产生结果的最大速率，`吞吐量界限`给出了CPE的最小界限。  
例如：因为只有一个整数乘法器，它的发射时间为1个时钟周期，处理器不可能支持每个时钟周期大于1条乘法的速度。另一方面，四个功能单元都可以执行整数加法，处理器就可能持续每个周期执行4个操作的速率。但是因为需要从内存读数据，这造成了另一个吞吐量界限。两个加载单元限制了处理器每个时钟周期最多只能读取两个数据值，从而使得吞吐量界限为0.5。

## 处理器操作的抽象模型 ##

我们可以用`数据流`表示处理器上执行的机器级程序性能，这是一种图形，展现不同操作之间的数据相关是如何限制它们的执行顺序的。这些限制形成了图中的`关键路径`，这是执行一组机器指令所需时钟周期数的下界。  
![在这里插入图片描述][20190517125441248.png]  
以乘法为例子，数据操作流有两条，分别是mul和add两个操作对于acc和data\[i\]的修改组成，如下：  
![在这里插入图片描述][20190517130431349.png]  
可见，如果mul需要5个周期，add需要1个周期，那么mul将成为关键路径，循环结束需要5n的周期。  
另外，从上面的CPE图可以看到，对于整数加法，CPE为1.27，而根据关键路径图预测的CPE应该为1.0，实际值比预测值慢，说明关键路径提供的只是下界。还有其他因素限制性能，比如可用的功能单元数量和任何一步中功能单元之间能够传递数值的数量等。  
总结一下，根据抽象数据流表示说明，combine4的关键路径长L\* n是由对acc的连续更新造成的，这条路径将CPE限制为最多L。对于整数加法，测量出的CPE大于关键路径所期望的CPE。

# 循环展开 #

循环展开是一种程序变换，通过增加每次迭代计算的元素的数量，减少循环的迭代次数。首先，这样可以减少不直接有助于程序结果的操作的数量，例如循环索引计算和条件分支；第二，它可以减少整个计算中关键路径上的操作数量。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 5]  
上述代码，第一个循环中，让limit = length - 1，防止循环访问越界；本例中选择步长k = 2，即每次data\[i\] + data\[i+1\] ，在这个基础上，如果length为偶数，第一个循环就可以直接计算完全，如果length为奇数，第一个循环就会剩余一个，剩余的用第二个循环计算，注意第二个循环继承了第一个循环结束时的i。  
归纳：如果像设置步长为k的循环，第一个循环上限为 length - k + 1，这种做法下称为k \* 1。  
![在这里插入图片描述][20190517131324380.png]

# 提高并行性 #

加法和乘法的功能单元是完全流水线化的，这说明它们可以每个时钟周期开始一个新操作，并且有些操作可以被多个功能单元执行。硬件有这种能力，但是代码不能利用这种能力，即使是循环展开也不行，这是因为我们将积累值放在一个单独的变量acc中。在前面的计算完成之前，都不能计算acc的新值。现在我们打破这种顺序，得到比延迟界限更好性能的方法。

## 多个积累变量 ##

类似整数加法或乘法这种可结合可交换的运算，可以把一组合并运算分割成多个部分，最后合并结果。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 6]  
上述代码的第一个循环中，就分别用了acc0和acc1来计算偶数位和奇数位，最后把acc0和acc1合并。这种做法称为2*2。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 7]  
可以看到已经打破了延迟界限设下的界限了。  
这种将循环展开k次，每次并行积累k个值，得到k \* k循环展开。当k足够大时，程序在所有情况下几乎都能达到吞吐量界限。  
只有保持能够执行该操作的所有功能单元流水线都是满的，程序才能达到这个操作的吞吐量界限。对于延迟为L，容量为C的机器，要求k>=C*L。  
在执行这种k \* k循环展开变化时，必须要看看最后能够保留原函数功能，补码运算是可交换和结合的，溢出时也是如此。所以对于整数数据类型，在所有情况下，k \* k循环得到的结果与原结果相同。而浮点乘法和加法不可结合，因此可能会得到不同结果。

## 重新结合变换 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 8]  
这里只是改变了第一个循环中acc等式中括号的位置，称为`重新结合变换`，括号改变了向量元素与积累值acc的合并顺序，产生了我们称为“2 \* 1a”的循环展开形式。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 9]  
重新结合变换能够减少计算中关键路径上操作的数量，更好地利用功能单元的流水线能力得更好的性能。大多数编译器不会对浮点数运算做重新结合，因为不能保证浮点数运算可结合。

# 优化合并代码的结果小结 #

![在这里插入图片描述][20190517141301330.png]  
分别使用了消除循环条件中的低效，循环体中的过程调用，不必要的内存引用（中间变量存储），循环展开，提高并行后，CPE提升了10~20倍。

# 一些限制因素 #

上文介绍了数据流图表示中，关键路径指明了执行该程序所需时间的一个基本的下界。也就是说，如果程序中有某条数据相关链，这条链上的所有延迟之和等于T，那么这个程序至少需要T个周期才能执行完。  
功能单元的吞吐量界限也是程序执行时间的一个下界。也就是所，假设一个程序一共需要N个某种运算的计算，而微处理器只有C个能执行这个操作的功能单元，并且这些单元的发射时间为I。那么这个程序至少需要N\*I/C个周期。

## 寄存器溢出 ##

如果并行度超过了可用的寄存器数量，那么编译器就会将某些临时值存放到内存中，通常是在运行时堆栈上分配空间。  
![在这里插入图片描述][20190517144921484.png]  
现代X86-64处理器有16个寄存器，并可以使用16个保存浮点数的寄存器，一旦循环变量的数量超过了可用寄存器的数量，CPE就变差了。

## 分支预测和预测错误处罚 ##

分支预测不准的时候回招致`预测错误处罚`，现代处理器的工作远远的超前于当前正在执行的指令，只要指令遵循一种简单的顺序，那么这种`指令流水线化`就能很好的工作。而出现分支预测时，使用`投机执行`的处理器会执行预测的目标处的指令，如果之后验证预测准确，就更新寄存器，反之撤销。一个C语言程序员怎么能够保证分支预测处罚不会阻碍程序的效率呢？  
1.不要过分关心可预测的分支  
我们已经看到错误的分支预测的影响可能非常大，但是这并不意味着所有的程序分支都会减缓程序的执行。  
2.书写合适用条件传送实现的代码  
分支预测只对有规律的模式可行，对于完全不可预测的，依赖于数据的任意特性的程序，预测会一塌糊涂。如果编译器能够产生使用`条件数据传送`，而不是使用`条件控制转移`的代码，可以极大地提高程序的性能。  
`条件控制转移`是指用条件控制程序执行的方向，然后去执行那个方向的运算，如下图：![在这里插入图片描述][20190517152140989.png]  
`条件数据传送`是先把两个方向上的运算都事先做好，然后用条件控制最终的赋值，如下图：  
![在这里插入图片描述][20190517152312647.png]  
有些表达条件行为的方法能够更直接地被翻译成条件数据传送。  
![在这里插入图片描述][20190517152639342.png]  
上述的代码在随机数据上测试，CPE为13.50，对于可预测数据，CPE为2.5~3.5。  
![在这里插入图片描述][20190517152743157.png]  
这个代码无论数据是任意，还是可预测，CPE都是4.0。  
通过这个例子我们知道，在合适的情况下，可以通过修改代码帮助编译器实现条件数据传送。

# 理解内存性能 #

这一小节专注一下加载（从内存到寄存器）和存储（从寄存器到内存）操作的程序性能。

## 加载的性能 ##

加载操作程序既依赖于流水线的能力，也依赖于加载单元的延迟。上面的CPE从来没到过0.5以下，因为所有的示例都需要从内存读一个值，对于两个加载单元来说，每一个时钟周期只能启动一条加载操作，所以CPE不可能小于0.5。对于每个必须加载k个值的程序，CPE不可能小于k/2。  
想要看一看加载操作的延迟产生的影响，需要让一条加载操作的结果决定下一条操作的地址。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 10]  
这个例子中，每次循环都依赖于指针 ls->next 读出的值。测试出CPE为4.0，这就是加载操作的延迟所决定的。

## 存储的性能 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 11]  
在这个例子中，示例A的CPE为1.3，示例B的CPE为7.3。这是因为，示例A中加载和存储的位置分别是a\[0\] 和 a\[1\]，没有数据相关；而示例B的加载和存储都是a\[0\]，这就产生了很大的数据相关，在微处理器执行加载和存储的时候，如果两个指令的地址是不同的，两个操作就可以独立进行；如果地址相同，就必须等到存放完成后，再加载。

# 应用：性能提高技术 #

1） 高级设计。为遇到的问题选择适当的算法和数据结构。要特别警觉，避免使用会渐进地产生糟糕性能的算法或编码技术。  
2） 基本编码原则。

*  消除连续的函数调用：可能的话，将计算移到循环外
 *  消除不必要的内存引用：引入临时变量来保存中间结果，最后将结果存到数组或全局变量中  
    3） 低级优化。
 *  展开循环，降低开销
 *  通过使用例如多个积累变量和重新结合等技术，提高指令并行
 *  用功能性风格重写条件操作，使得编译采用条件数据传送

# 确认和消除性能瓶颈 #

之前给出的都是小程序的优化，对于大程序的优化没那么简单，连知道应该优化什么地方都很难，这一节介绍了一种Unix系统下`代码剖析程序`：GPROF，用来分析某程序中每个函数花费的CPU时间，和每个函数被调用的次数，不多介绍了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70]: /images/20220201/144ec067cb0547e19ec9a98f2d8d6f47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 1]: /images/20220201/6b629c4c13ba4687b42cef1c79ef35db.png
[20190514153029926.png]: /images/20220201/40cedbdcff0644b2b03cf517555eca4b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 2]: /images/20220201/54d4b87447764577a3a30a1441af390d.png
[2019051415441648.png]: /images/20220201/7ffd14711ed649899958632b0156101f.png
[20190515084911360.png]: /images/20220201/1bd46727534e4a2096ce9b9fc7255bf1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 3]: /images/20220201/9731a7d7fd8b4b6cafed3ce460554307.png
[20190515085909740.png]: /images/20220201/70b69ed078b04c1f8b7a09f82850c4ca.png
[20190515090808693.png]: /images/20220201/6269ce8edcdf46a3ac9b1f6d7612094b.png
[20190515090822824.png]: /images/20220201/25140a4f6bce49f0b1c427b76128279b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 4]: /images/20220201/b529191fb4b6422d9fbc10f525610c80.png
[2019051511534380.png]: /images/20220201/b3e2db8b6ac1403aa0213e4f65ec4d0b.png
[20190517125441248.png]: /images/20220201/51c40b56957d4f1894fb348b68134e18.png
[20190517130431349.png]: /images/20220201/9326257fc5fe444aae56bd58454ad886.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 5]: /images/20220201/44f4c61f9f4a4ec3ad6a8132d0096f3f.png
[20190517131324380.png]: /images/20220201/5fd8afde3be04eb197a18e1cd6ef0a6e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 6]: /images/20220201/cfa36150896b42a894bb2e859460919b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 7]: /images/20220201/efd653f44f9648ef9a7900741db542b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 8]: /images/20220201/8ec48d74a2e84f72bc6ec082a2bd049c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 9]: /images/20220201/533c96c5dce04887b5ac9b14217e42b1.png
[20190517141301330.png]: /images/20220201/a1703bcdd0f94f6da9e1df4f6790d8a2.png
[20190517144921484.png]: /images/20220201/14b7004b639a4be98cb0f097bb5acd5c.png
[20190517152140989.png]: /images/20220201/d76c47d25778456b96ab08ff6b614d01.png
[20190517152312647.png]: /images/20220201/3069de92bfc34f1a9b318458b5ec7258.png
[20190517152639342.png]: /images/20220201/40718a84af65476e8d762d24499bb0eb.png
[20190517152743157.png]: /images/20220201/616458b5e25643afbc9099482ec4b064.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 10]: /images/20220201/677103b9d4de4cbabe77f27185b338c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1MDY1ODc1_size_16_color_FFFFFF_t_70 11]: /images/20220201/74dd4d3abeae49e68546b7851204d412.png