为什么处理一个排序数组要比处理一个未排序的数组更快？

以前无意看到了stackoverflow上面的一个帖子：

为什么这段代码在数据排序后的运行时间要比排序前快6倍？

1234567891011121314151617181920212223242526272829303132333435

#include <algorithm> #include <ctime> #include <iostream>   int main () { // Generate data const unsigned arraySize = 32768 ; int data [ arraySize ];   for ( unsigned c = 0 ; c < arraySize ; ++ c ) data [ c ] = std :: rand () % 256 ;   // !!! With this, the next loop runs faster std :: sort ( data , data + arraySize );   // Test clock_t start = clock (); long long sum = 0 ;   for ( unsigned i = 0 ; i < 100000 ; ++ i ) { // Primary loop for ( unsigned c = 0 ; c < arraySize ; ++ c ) { if ( data [ c ] >= 128 ) sum += data [ c ]; } }   double elapsedTime = static_cast < double > ( clock () - start ) / CLOCKS_PER_SEC ;   std :: cout << elapsedTime << std :: endl ; std :: cout << "sum = " << sum << std :: endl ; }

view raw gistfile1.cpp hosted with ❤ by  GitHub

如果没有这行std::sort(data, data + arraySize);, 代码一共运行 11.54 秒.

而如果数据先被排序，那么只需要运行 1.93 秒.

一开始我以为只是语言或者编译器的问题，所以我又用java试了一遍：

123456789101112131415161718192021222324252627282930313233343536

import java.util.Arrays ; import java.util.Random ;   public class Main { public static void main ( String [] args ) { // Generate data int arraySize = 32768 ; int data [] = new int [ arraySize ];   Random rnd = new Random ( 0 ); for ( int c = 0 ; c < arraySize ; ++ c ) data [ c ] = rnd . nextInt () % 256 ;   // !!! With this, the next loop runs faster Arrays . sort ( data );   // Test long start = System . nanoTime (); long sum = 0 ;   for ( int i = 0 ; i < 100000 ; ++ i ) { // Primary loop for ( int c = 0 ; c < arraySize ; ++ c ) { if ( data [ c ] >= 128 ) sum += data [ c ]; } }   System . out . println (( System . nanoTime () - start ) / 1000000000.0 ); System . out . println ( "sum = " + sum ); } }

view raw gistfile1.java hosted with ❤ by  GitHub

结果还是刚才那样，只不过差距缩小了一些。

之后我又想会不会是因为排序算法把数据存到了cache中，但是我马上意识到这种想法是多么愚蠢，因为数组也是刚刚才生成的。

到底是为什么呢？为什么排序好的数组运行的要比没有排过序的更快一些？这个程序只是把一些独立的项相加，数组顺序应该没关系啊？

之后的答案才是全文的亮点，具体原文我就不翻译了，感兴趣的同学可以看看Coolshell的《代码执行的效率》一文中的翻译。简单的说，就是当处理器执行到某一步时，有两种分支指令的可能，此时处理器就需要选择一条来继续执行。如果这时猜对了，那么就可以继续执行下面的语句，但是如果猜错了，就需要在发现错误后及时终止当前指令的执行，返回分叉处。SO站的答案还以火车岔路口的扳道工做类比来形象的说明这个问题。但是就在我们以为自己已经懂了的时候，稍微细想就会发现这种处理方式似乎与我们原有的对于处理器和程序的印象不太符合。任何一个程序经过编译不都是会形成汇编指令吗？处理器的处理过程不就是在机械的按步骤在执行那些指令吗？为什么会有这种所谓的“猜测”存在呢？这还要从编译器的工作方法说起。

汇编是如何实现循环的？

要想搞清楚计算机在运行上面那段代码时究竟做了什么事，首先需要在汇编的层面上看看处理器是怎么真正的执行这段程序的。

一下面一段C语言代码为例:(本段代码摘自CSAPP)

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960

#include <stdio.h> #include <stdlib.h>   #define IDENT 1 #define OPER * typedef int data_t ;   typedef struct { int len ; data_t * data ; } vec_rec , * vec_ptr ;   data_t * get_vec_start ( vec_ptr v ){ return v -> data ; }   int vec_length ( vec_ptr v ) { return v -> len ; }   vec_ptr new_vec ( int len ){ /* allocate header structure */ vec_ptr result = ( vec_ptr ) malloc ( sizeof ( vec_rec )); if ( ! result ) return NULL ; /*Couldn't allocate storage*/ result -> len = len ; /* Allocate array */ if ( len > 0 ) { data_t * data = ( data_t * ) calloc ( len , sizeof ( data_t )); if ( ! data ) { free (( void * ) result ); return NULL ; } result -> data = data ; } else result -> data = NULL ; return result ; }   void combine4 ( vec_ptr v , data_t * dest ){ int i ; int length = vec_length ( v ); data_t * data = get_vec_start ( v ); data_t x = IDENT ;   * dest = IDENT ; for ( i = 0 ; i < length ; i ++ ) x = x OPER data [ i ]; * dest = x ; }   int main (){ int a ; vec_ptr v ; v = new_vec ( 3 ); combine4 ( v , & a ); }

view raw gistfile1.cpp hosted with ❤ by  GitHub

下面我们只来关注50-52行，其他代码是为了和CSAPP保持统一并且能运行而写的：

123	for ( i = 0 ; i < length ; i ++ ) x = x OPER data [ i ]; * dest = x ;

view raw gistfile1.cpp hosted with ❤ by  GitHub

我们用gcc进行编译，gdb调试显示汇编代码：

1234567891011

00401488 mov - 0x4 ( % ebp ), % eax 0040148 B shl $ 0x2 , % eax 0040148 E add - 0x10 ( % ebp ), % eax 00401491 mov ( % eax ), % eax 00401493 mov - 0x8 ( % ebp ), % edx 00401496 imul % edx , % eax 00401499 mov % eax , - 0x8 ( % ebp ) 0040149 C incl - 0x4 ( % ebp ) 0040149 F mov - 0x4 ( % ebp ), % eax 004014 A2 cmp - 0xc ( % ebp ), % eax 004014 A5 jl 0x401488

view raw gistfile1.asm hosted with ❤ by  GitHub

之后再对照监视变量：

通过%ebp（栈帧寄存器）以及偏移量就可以知道这个局部栈的构造：

1234567

| |高地址 | | <- 28 fefb - 28 fef8 ( $ ebp ) | i | <- 28 fef7 - 28 fef4 | x | <- 28 fef3 - 28 fef0 | length | <- 28 feef - 28 feec | base | <- 28 feeb - 28 fee7 ----------- 低地址

view raw gistfile1.asm hosted with ❤ by  GitHub

还有一点需要注意：因为栈是从高地址向低地址实现分配的，但是系统写数据时仍然是从低地址向高地址写，所以要想访问栈顶元素($ebp)需要将指针指向$ebp-4(即28fef4)，而不是28fef8

接下来我们就看看这段汇编代码是怎么样实现循环和循环边界的判断的：

1234567891011

00401488 mov - 0x4 ( % ebp ), % eax ;i赋给$eax（i已被初始化为0） 0040148 B shl $ 0x2 , % eax ;$eax向左移2位（即乘4来计算偏移量） 0040148 E add - 0x10 ( % ebp ), % eax ;$eax加上基址，计算出data[i]的地址，赋给$eax 00401491 mov ( % eax ), % eax ;取出data[i]的数据，并且赋给$eax 00401493 mov - 0x8 ( % ebp ), % edx ;取出x，赋给%edx 00401496 imul % edx , % eax ;$eax = $edx * $eax 00401499 mov % eax , - 0x8 ( % ebp ) ;x = $eax 0040149 C incl - 0x4 ( % ebp ) ;i++ 0040149 F mov - 0x4 ( % ebp ), % eax ;i赋给eax 004014 A2 cmp - 0xc ( % ebp ), % eax ;比较length和i 004014 A5 jl 0x401488 ;如果i < length，跳至00401488(即这段代码开始)，实现循环

view raw gistfile1.asm hosted with ❤ by  GitHub

通过分析可以看到，汇编语言基本是在C语言的基础上加了中间的寄存器操作来实现赋值以及比较。这时，原本连贯的一句赋值语句 a = b + c 会被分解为两条指令，分别是 register = b + c 和 a = register。而循环边界的判断也被分解成若干条语句，其中循环的实现是由单独的一条指令来完成的。也就是说，如果当处理器单独执行最后一条语句时，处理器并没有可参照的数据，从而不知是否应该执行。

但是这毕竟一段完整的程序，虽然零散但是严密，如果处理器却是严格按照流程来执行，也不会发生任何歧义的解释。那么又为什么会出现处理器“猜测”的情况出现呢？

指令流水线（Instruction Pipeline）

通过上文我们已经知道，当程序被编译为汇编程序后，整段程序会被拆分得很零散，并且被拆分成了几种基本的指令：赋值，累加，乘法，比较，跳转。而处理器也只能一次执行一条指令。但是再去深入观察处理器执行的流程时，我们会发现执行每条汇编级别的指令都被拆分成了更基本的步骤，包括从内存中读指令到寄存器，对指令进行解析，执行指令，将结果写入寄存器，写入内存等。而这时，处理器并非只能处理其中的一个步骤，而是能够同时处理不同种类的一个步骤。也就是说，处理器可以同时对某条指令进行解析，也可以同时对将某个运算结果写入寄存器，因为这些步骤在电路级别是相互独立互不影响的。

由于处理器的这种独特性质，所以一个加速处理器处理的方法就诞生了。既然处理器在一个时钟周期内能够最多同时处理多种操作，那么就应该尽可能的让处理器多同时处理才行。但是由于每条指令的顺序是固定并且有依赖关系的（只有先拿到指令后才能译码，只有读懂指令后才能执行），所以我们在一开始（第一个时钟周期）只能让处理器取第一条指令。但是当处理器进行到第二步时，也就是处理器对第一条指令进行译码时，我们就可以让处理器同时取出第二条指令，因为取指令和译码是两个不同的阶段，彼此独立。以此类推，每当我们的第一条指令执行到第n步时，第二条指令也已经执行到了第n-1步，第三条指令执行到了n-2步……这样就很大程度上提高了处理器运行程序的效率。这种机制就叫做指令流水线（Instruction Pipeline）。

虽然指令流水线确实提高了处理器的处理速度，但是也存在着很严重的问题。因为有些指令不是独立的，而是依赖于上一条指令的执行情况。比如在执行从一个内存地址取出数据进行加法运算时，也许上一条指令已经改变了这个数据的值，但是还没有来的及写入内存，而这句就已经从内存地址取出了一个旧的值，这样就会造成运算错误。而在本例中也一样，因为在最后一条指令执行时，需要先判断两个数的大小才能决定是否跳转，但是由于上一条比较指令的结果还没有没保存，所以跳转指令就面临两难境地。

虽然这个问题是很严重的，它似乎都影响到了计算的准确性，但是因此而把指令流水线机制放弃掉也有因噎废食之嫌。于是计算机做出一个保证准确性的前提之下的尽量保持高效率的解决方案：一旦发现某个参与提前计算的值在之后被修改，那么就立即停止那个提前计算的流水线以及其之后的流水线，废弃掉所有的已经计算出来的结果，重新计算。这样一来，虽然似乎效率又变的和没有使用流水线一样了，但是至少保住了计算的精确性。

而对于跳转呢？跳转也是同一个道理。当某流水线执行到跳转指令而是否跳转还未确定时，通常处理器都会根据某个算法来计算是否要冒险跳转。而这种算法虽然很多，但是大多也都基于之前的跳转结果而来。一旦发现跳转错误，就立即终止跳转之后的所有流水线流程，而这样对效率的损失也是显而易见的。[1]

为什么处理一个排序数组要比处理一个未排序数组更快？

这样，我们也就清楚在排序时到底发生了什么事了。这篇文章一开始的程序是要判断某个数是否大于128，如果大于那么就累加，否则跳过。而在处理器执行跳转语句时，依据便是data[i]与128的大小比较。当这组数据大小随意排列时，显然处理器要“猜测”（其实是确定的算法）错误很多次，因为理想状态下只有0.5的机会猜对。而当这组数据已经排好序时，一开始有可能处理器会猜错，但是当处理器发现之前的几次的跳转结果都相同时，算法会倾向于继续猜测这种状况，所以才对的几率会大很多。只有当遍历的数据超过128时，处理器才会再度猜错，不过这也使一时的。如果处理器采用的是“按照上一次的结果来猜测”的算法的话，也只是有一次流水线会被停掉。所以整段代码几乎是全部按多调流水线执行下来的，当然会快很多。而在上面的问题中，这种效率差距竟然达到了6倍之多。

Note

1. 其实近代的IA32处理器为了避免跳转错误带来的成本代价，增添了比较跳转指令cmov（即conditional move）。这条指令先执行两个分支的代码并储存结果，之后再判断条件的成立情况直接读取先前计算出的结果（这个过程中并没有跳转指令参与）。虽然多执行了很多代码（连另一种情况也计算了），但是总体上看仍然要比盲目跳转遇到损失的代价要小。

Reference

1. Computer Systems: A Programmer's Perspective
2. Branch_predictor from Wikipedia
3. Instruction_pipeline from Wikipedia
4. 《代码执行的效率》 from Coolshell

原创文章，转载请注明： 转载自Binary Think

http://www.binarythink.net/2012/09/why-sorted-array-faster/