少写点if-else吧，它的效率有多低你知道吗？ / 开普饭

首先看一段经典的代码，并统计它的执行时间：

// test_predict.cc#include <algorithm>#include <ctime>#include <iostream>

int main() { const unsigned ARRAY_SIZE = 50000; int data[ARRAY_SIZE]; const unsigned DATA_STRIDE = 256;

for (unsigned c = 0; c < ARRAY_SIZE; ++c) data[c] = std::rand() % DATA_STRIDE;

std::sort(data, data + ARRAY_SIZE);

{ // 测试部分 clock_t start = clock(); long long sum = 0;

for (unsigned i = 0; i < 100000; ++i) { for (unsigned c = 0; c < ARRAY_SIZE; ++c) { if (data[c] >= 128) sum += data[c]; } }

double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;

std::cout << elapsedTime << '\n'; std::cout << 'sum = ' << sum << '\n'; } return 0;}~/test$ g++ test_predict.cc ;./a.out7.95312sum = 480124300000

此程序的执行时间是7.9秒，如果把排序那一行代码注释掉，即

// std::sort(data, data + ARRAY_SIZE);

结果为：

~/test$ g++ test_predict.cc ;./a.out24.2188sum = 480124300000

改动后的程序执行时间变为了24秒。

其实只改动了一行代码，程序执行时间却有3倍的差距，而且看上去数组是否排序与程序执行速度貌似没什么关系，这里面其实涉及到CPU分支预测的知识点。

提到分支预测，首先要介绍一个概念：流水线。

拿理发举例，小理发店一般都是一个人工作，一个人洗剪吹一肩挑，而大理发店分工明确，洗剪吹都有特定的员工，第一个人在剪发的时候，第二个人就可以洗头了，第一个人剪发结束吹头发的时候，第二个人可以去剪发，第三个人就可以去洗头了，极大的提高了效率。

这里的洗剪吹就相当于是三级流水线，在CPU架构中也有流水线的概念，如图：

在执行指令的时候一般有以下几个过程：

取指：Fetch
译指：Decode
执行：execute
回写：Write-back

流水线架构可以更好的压榨流水线上的四个员工，让他们不停的工作，使指令执行的效率更高。

再谈分支预测，举个经典的例子：

火车高速行驶的过程中遇到前方有个岔路口，假设火车内没有任何通讯手段，那火车就需要在岔路口前停下，下车询问别人应该选择哪条路走，弄清楚路线后后再重新启动火车继续行驶。高速行驶的火车慢速停下，再重新启动后加速，可以想象这个过程浪费了多少时间。

有个办法，火车在遇到岔路口前可以猜一条路线，到路口时直接选择这条路行驶，如果经过多个岔路口，每次做出选择时都能选择正确的路口行驶，这样火车一路上都不需要减速，速度自然非常快。但如果火车开过头才发现走错路了，就需要倒车回到岔路口，选择正确的路口继续行驶，速度自然下降很多。所以预测的成功率非常重要，因为预测失败的代价较高，预测成功则一帆风顺。

计算机的分支预测就如同火车行驶中遇到了岔路口，预测成功则程序的执行效率大幅提高，预测失败程序的执行效率则大幅下降。

CPU都是多级流水线架构运行，如果分支预测成功，很多指令都提前进入流水线流程中，则流水线中指令运行的非常顺畅，而如果分支预测失败，则需要清空流水线中的那些预测出来的指令，重新加载正确的指令到流水线中执行，然而现代CPU的流水线级数非常长，分支预测失败会损失10-20个左右的时钟周期，因此对于复杂的流水线，好的分支预测方法非常重要。

预测方法主要分为静态分支预测和动态分支预测：

静态分支预测：听名字就知道，该策略不依赖执行环境，编译器在编译时就已经对各个分支做好了预测。

动态分支预测：即运行时预测，CPU会根据分支被选择的历史纪录进行预测，如果最近多次都走了这个路口，那CPU做出预测时会优先考虑这个路口。

tips：这里只是简单的介绍了分支预测的方法，更多的分支预测方法资料大家可关注公众号回复分支预测关键字领取。

了解了分支预测的概念，我们回到最开始的问题，为什么同一个程序，排序和不排序的执行速度相差那么多。

因为程序中有个if条件判断，对于不排序的程序，数据散乱分布，CPU进行分支预测比较困难，预测失败的频率较高，每次失败都会浪费10-20个时钟周期，影响程序运行的效率。而对于排序后的数据，CPU根据历史记录比较好判断即将走哪个分支，大概前一半的数据都不会进入if分支，后一半的数据都会进入if分支，预测的成功率非常高，所以程序运行速度很快。

如何解决此问题？总体思路肯定是在程序中尽量减少分支的判断，方法肯定是具体问题具体分析了，对于该示例程序，这里提供两个思路削减if分支。

方法一：使用位操作：

int t = (data[c] - 128) >> 31;sum += ~t & data[c];

方法二：使用表结构：

#include <algorithm>#include <ctime>#include <iostream>

int main() { const unsigned ARRAY_SIZE = 50000; int data[ARRAY_SIZE]; const unsigned DATA_STRIDE = 256;

for (unsigned c = 0; c < ARRAY_SIZE; ++c) data[c] = std::rand() % DATA_STRIDE;

int lookup[DATA_STRIDE]; for (unsigned c = 0; c < DATA_STRIDE; ++c) { lookup[c] = (c >= 128) ? c : 0; }

std::sort(data, data + ARRAY_SIZE);

{ // 测试部分 clock_t start = clock(); long long sum = 0;

for (unsigned i = 0; i < 100000; ++i) { for (unsigned c = 0; c < ARRAY_SIZE; ++c) { // if (data[c] >= 128) sum += data[c]; sum += lookup[data[c]]; } }

double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC; std::cout << elapsedTime << '\n'; std::cout << 'sum = ' << sum << '\n'; } return 0;}

其实Linux中有一些工具可以检测出分支预测成功的次数，有valgrind和perf，使用方式如图：

图片截自下方参考资料中

条件分支的使用会影响程序执行的效率，我们平时开发过程中应该尽可能减少在程序中随意使用过多的分支，能避免则避免。

更多的分支预测方法资料大家可关注公众号回复分支预测关键字领取。

拓展阅读：

《虚函数真的就那么慢吗？它的开销究竟在哪里？来看这4段代码！》

想必很多人都听说过虚函数开销大，貌似很多答案都说是因为虚函数表导致的那一次间接调用，真的如此吗？

直接看下面这两段代码：

#include <cmath>#include 'timer.h'struct Base {   public:    virtual int f(double i1, int i2) { return static_cast<int>(i1 * log(i1)) * i2; }};int main() {    TimerLog t('timer');    Base *a = new Base();    int ai = 0;    for (int i = 0; i < 1000000000; i++) {        ai += a->f(i, 10);    }    cout << ai << endl;}

执行时间：12.895s

#include <cmath>#include 'timer.h'struct Base { public: int f(double i1, int i2) { return static_cast<int>(i1 * log(i1)) * i2; }};

int main() { TimerLog t('timer'); Base *a = new Base(); int ai = 0; for (int i = 0; i < 1000000000; i++) { ai += a->f(i, 10); } cout << ai << endl;}

执行时间：12.706s

这两段代码的执行时间几乎没有区别，可见虚函数表导致的那一次函数间接调用并不浪费时间，所以虚函数的开销并不在重定向上，这一次重定向基本上不影响程序性能。

那它的开销究竟在哪里呢？看下面两段代码，这两段代码和上面相比只改动了一行：

#include <cmath>#include 'timer.h'struct Base {   public:    virtual int f(double i1, int i2) { return static_cast<int>(i1 * log(i1)) * i2; }};int main() {    TimerLog t('timer');    Base *a = new Base();    int ai = 0;    for (int i = 0; i < 1000000000; i++) {        ai += a->f(10, i); // 这里有改动    }    cout << ai << endl;}

执行时间：436ms

#include <cmath>#include 'timer.h'struct Base { public: int f(double i1, int i2) { return static_cast<int>(i1 * log(i1)) * i2; }};

int main() { TimerLog t('timer'); Base *a = new Base(); int ai = 0; for (int i = 0; i < 1000000000; i++) { ai += a->f(10, i); // 这里有改动 } cout << ai << endl;}

执行时间154ms

这里看到，仅仅改变了一行代码，虚函数调用就比普通函数慢了几倍，为什么？

虚函数其实最主要的性能开销在于它阻碍了编译器内联函数和各种函数级别的优化，导致性能开销较大，在普通函数中log(10)会被优化掉，它就只会被计算一次，而如果使用虚函数，log(10)不会被编译器优化，它就会被计算多次。如果代码中使用了更多的虚函数，编译器能优化的代码就越少，性能就越低。

虚函数通常通过虚函数表来实现，在虚表中存储函数指针，实际调用时需要间接访问，这需要多一点时间。

然而这并不是虚函数速度慢的主要原因，真正原因是编译器在编译时通常并不知道它将要调用哪个函数，所以它不能被内联优化和其它很多优化，因此就会增加很多无意义的指令（准备寄存器、调用函数、保存状态等），而且如果虚函数有很多实现方法，那分支预测的成功率也会降低很多，分支预测错误也会导致程序性能下降。

如果你想要写出高性能代码并频繁的调用虚函数，注意如果用其它的方式（例如if-else、switch、函数指针等）来替换虚函数调用并不能根本解决问题，它还有可能会更慢，真正的问题不是虚函数，而是那些不必要的间接调用。

正常的函数调用：

复制栈上的一些寄存器，以允许被调用的函数使用这些寄存器；
将参数复制到预定义的位置，这样被调用的函数可以找到对应参数；
入栈返回地址；
跳转到函数的代码，这是一个编译时地址，因为编译器/链接器硬编码为二进制；
从预定义的位置获取返回值，并恢复想要使用的寄存器。

而虚函数调用与此完全相同，唯一的区别就是编译时不知道函数的地址，而是：

从对象中获取虚表指针，该指针指向一个函数指针数组，每个指针对应一个虚函数；
从虚表中获取正确的函数地址，放到寄存器中；
跳转到该寄存器中的地址，而不是跳转到一个硬编码的地址。

通常，使用虚函数没问题，它的性能开销也不大，而且虚函数在面向对象代码中有强大的作用。

但是不能无脑使用虚函数，特别是在性能至关重要的或者底层代码中，而且大项目中使用多态也会导致继承层次很混乱。

那么有什么好方法替代虚函数呢？这里提供几个思路，读者请持续关注，后续会具体讲解：

使用访问者模式来使类层次结构可扩展；
使用普通模板替代继承和虚函数；
C++20中的concepts用来替代面向对象代码；
使用variants替代虚函数或模板方法。

这几种方法是Michael Spertus大佬介绍的，各有各的优缺点，作者都会用，但什么情况下使用哪个，取决于你自己的判断，这里只是教你了一个工具，什么时候用都取决于你自己。

END

来源：程序喵大人，作者：程序喵大人

少写点if-else吧，它的效率有多低你知道吗？

相关推荐