Why is processing a sorted array faster than an unsorted array?
这是我在逛 Stack Overflow 时遇见的一个高分问题：Why is processing a sorted array faster than an unsorted array?，我觉得这是一个非常好的用来讲分支预测（Branch Prediction）的例子，分享给大家看看
一、问题引入
先看这个代码：
#include <algorithm>
#include <ctime>
#include <iostream>
#include <stdint.h>
int main() {
uint32_t arraySize = 20000;
uint32_t data[arraySize];
for (uint32_t i = 0; i < arraySize; ++ i) {
data[i] = std::rand() % 256;
}
// !!! With this, the next loop runs faster
std::sort(data, data + arraySize);
clock_t start = clock();
uint64_t sum = 0;
for (uint32_t cnt = 0; cnt < 100000; ++ cnt) {
for (uint32_t i = 0; i < arraySize; ++ i) {
if (data[i] > 128) {
sum += data[i];
}
}
}
double processTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
std::cout << "processTime: " << processTime << std::endl;
std::cout << "sum: " << sum << std::endl;
return 0;
};
注意：这里特地没有加随机数种子是为了确保 data 数组中的伪随机数始终不变，为接下来的对比分析做准备，尽可能减少实验中的变量
我们编译并运行这段代码（gcc 版本 4.1.2，太高的话会被优化掉）：
$ g++ a.cpp -o a -O3
$ ./a
processTime: 1.78
sum: 191444000000
下面，把下面的这一行注释掉，然后再编译并运行：
std::sort(data, data + arraySize);
$ g++ a.cpp -o b -O3
$ ./b
processTime: 10.06
sum: 191444000000
注意到了吗？去掉那一行排序的代码后，整个计算时间被延长了十倍！
二、是 Cache Miss 导致的吗？
答案显然是否定的。cache miss 率并不会因为数组是否排序而改变，因为两份代码取数据的顺序是一样的，数据量大小是一样的，数据布局也是一样的，并且在同一台机器上运行，并没有任何差别，所以可以肯定的是：和 cache miss 无任何关系
为了验证我们的分析，可以用 valgrind 提供的 cachegrind tool 查看 cache miss 率：
$ valgrind --tool=cachegrind ./a
==26548== Cachegrind, a cache and branch-prediction profiler
==26548== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==26548== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==26548== Command: ./a
==26548==
--26548-- warning: L3 cache found, using its data for the LL simulation.
--26548-- warning: specified LL cache: line_size 64 assoc 20 total_size 15,728,640
--26548-- warning: simulated LL cache: line_size 64 assoc 30 total_size 15,728,640
processTime: 68.57
sum: 191444000000
==26548==
==26548== I refs: 14,000,637,620
==26548== I1 misses: 1,327
==26548== LLi misses: 1,293
==26548== I1 miss rate: 0.00%
==26548== LLi miss rate: 0.00%
==26548==
==26548== D refs: 2,001,434,596 (2,000,993,511 rd + 441,085 wr)
==26548== D1 misses: 125,115,133 ( 125,112,303 rd + 2,830 wr)
==26548== LLd misses: 7,085 ( 4,770 rd + 2,315 wr)
==26548== D1 miss rate: 6.3% ( 6.3% + 0.6% )
==26548== LLd miss rate: 0.0% ( 0.0% + 0.5% )
==26548==
==26548== LL refs: 125,116,460 ( 125,113,630 rd + 2,830 wr)
==26548== LL misses: 8,378 ( 6,063 rd + 2,315 wr)
==26548== LL miss rate: 0.0% ( 0.0% + 0.5% )
$ valgrind --tool=cachegrind ./b
==13898== Cachegrind, a cache and branch-prediction profiler
==13898== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==13898== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==13898== Command: ./b
==13898==
--13898-- warning: L3 cache found, using its data for the LL simulation.
--13898-- warning: specified LL cache: line_size 64 assoc 20 total_size 15,728,640
--13898-- warning: simulated LL cache: line_size 64 assoc 30 total_size 15,728,640
processTime: 76.7
sum: 191444000000
==13898==
==13898== I refs: 13,998,930,559
==13898== I1 misses: 1,316
==13898== LLi misses: 1,281
==13898== I1 miss rate: 0.00%
==13898== LLi miss rate: 0.00%
==13898==
==13898== D refs: 2,000,938,800 (2,000,663,898 rd + 274,902 wr)
==13898== D1 misses: 125,010,958 ( 125,008,167 rd + 2,791 wr)
==13898== LLd misses: 7,083 ( 4,768 rd + 2,315 wr)
==13898== D1 miss rate: 6.2% ( 6.2% + 1.0% )
==13898== LLd miss rate: 0.0% ( 0.0% + 0.8% )
==13898==
==13898== LL refs: 125,012,274 ( 125,009,483 rd + 2,791 wr)
==13898== LL misses: 8,364 ( 6,049 rd + 2,315 wr)
==13898== LL miss rate: 0.0% ( 0.0% + 0.8% )
对比可以发现，他们俩的 cache miss rate 和 cache miss 数几乎相同，因此确实和 cache miss 无关
三、Branch Prediction
使用到 valgrind 提供的 callgrind tool 可以查看分支预测失败率：
$ valgrind --tool=callgrind --branch-sim=yes ./a
==29373== Callgrind, a call-graph generating cache profiler
==29373== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==29373== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==29373== Command: ./a
==29373==
==29373== For interactive control, run 'callgrind_control -h'.
processTime: 288.68
sum: 191444000000
==29373==
==29373== Events : Ir Bc Bcm Bi Bim
==29373== Collected : 14000637633 4000864744 293254 23654 395
==29373==
==29373== I refs: 14,000,637,633
==29373==
==29373== Branches: 4,000,888,398 (4,000,864,744 cond + 23,654 ind)
==29373== Mispredicts: 293,649 ( 293,254 cond + 395 ind)
==29373== Mispred rate: 0.0% ( 0.0% + 1.7% )
可以看到，在计算 sum 之前对数组排序，分支预测失败率非常低，几乎相当于没有失败
$ valgrind --tool=callgrind --branch-sim=yes ./b
==23202== Callgrind, a call-graph generating cache profiler
==23202== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==23202== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23202== Command: ./b
==23202==
==23202== For interactive control, run 'callgrind_control -h'.
processTime: 287.12
sum: 191444000000
==23202==
==23202== Events : Ir Bc Bcm Bi Bim
==23202== Collected : 13998930783 4000477534 1003409950 23654 395
==23202==
==23202== I refs: 13,998,930,783
==23202==
==23202== Branches: 4,000,501,188 (4,000,477,534 cond + 23,654 ind)
==23202== Mispredicts: 1,003,410,345 (1,003,409,950 cond + 395 ind)
==23202== Mispred rate: 25.1% ( 25.1% + 1.7% )
而这个未排序的就不同了，分支预测失败率达到了 25%。因此可以确定的是：两份代码在运行时 CPU 分支预测失败率不同导致了运行时间的不同
四、分支预测
那么到底什么是分支预测，分支预测的策略是什么呢？这两个问题我觉得 Mysticial 的回答 解释的非常好：
假设我们现在处于 1800 年代，那会长途通信或者无线通信还没有出现。你是某个铁路分叉口的操作员，当你正在打盹的时候，远方传来了火车轰隆隆的声音。你知道又有一辆列车开过来了，但是你不知道它要走哪条路，因此列车不得不停下来，在得知它要去哪个方向后，你把开关拨向正确的位置，列车缓缓启动驶向远方。
但是列车很重，自身的惯性很大，停止和启动都需要花很长很长的时间。有什么方法能让列车更快的到达目的地吗？有：你来猜测列车将驶向哪个方向。
如果你猜中了，列车继续前进；如果没有猜中：司机发现路不对后刹车、倒车、冲你发一顿火，最后你把开关拨到另一边，然后司机启动列车，走另一条路。
现在让我们来看看那条 if 语句：
if (data[i] >= 128) {
sum += data[i]
}
现在假设你是 CPU，当遇到这个 if 语句时，接下来该做什么：把 data[i] 累加到 sum 上面还是什么都不做？
怎么办？难道是暂停下来，等待 if 表达式算出结果，如果是 true 就执行 sum += data[i]，否则什么也不做？
经过几十年的发展，现代处理器异常复杂并拥有者超长的 pipeline，它需要花费很长的时间“暂停”和重新执行命令，为了加快执行速度，处理器需要猜测接下来要做什么，也就是说：你先忽略 if 表达式的结果，让它一边算去，你选择其中一个分支继续执行下去。
如果你猜对了，程序继续执行；如果猜错了，需要 flush pipeline、回滚到分支判断那、选择另一个分支执行下去。
如果每次都猜中：程序执行过程中永远不会出现中途暂停的情况
如果大多数都猜错了：你将消耗大量的时间在“暂停、回滚、重新执行”上面
这就是分支预测。那么 CPU 在猜测接下来要执行哪个分支时有什么策略吗？当然是根据已有的经验啦：根据历史经验寻找一个模式
如果过去 99% 的火车都走了左边，你就猜测下次火车到来还是会走左边；如果是左右交替着走，那么每次火车来的时候你把开关拨向另一边就可以了；如果每三辆车走右边后会有一辆车走左边，那么你也对应的猜测并操作开关...
也就是说：从火车的行进方向历史中找到一个固有的模式，然后按照这个模式猜测下次火车将走哪个方向。这种工作方式和处理器的分支预测器非常相似
大多数应用程序都有表现良好的分支选择（让 CPU 有迹可循）模式，因此现代分支预测器基本上都有着 90% 以上的命中率。但是当面临有着无法识别的分支选择模式时，分支预测器的命中率极度低下，毫无可用性可言，比如上面未排序的随机数组 data
关于分支预测的更多解释，感兴趣的话大家可以看看维基百科的解释：Branch predictor
