java 为什么处理排序数组比处理未排序数组更快？

数据排序后性能显着提高的原因是分支预测惩罚被删除，正如Mysticial 的回答中所解释的那样。

现在，如果我们看一下代码

if (data[c] >= 128)
    sum += data[c];

我们可以发现这个特定if... else...分支的含义是在满足条件时添加一些东西。这种类型的分支可以很容易地转换为条件移动语句，该语句将在系统中编译为条件移动指令：cmovl，x86。分支和潜在的分支预测惩罚被移除。

C因此，在C++中，将直接编译（没有任何优化）到条件移动指令中的语句x86是三元运算符... ? ... : ...。所以我们把上面的语句改写成等价的：

sum += data[c] >=128 ? data[c] : 0;

在保持可读性的同时，我们可以检查加速因子。

在 Intel Core i7 -2600K @ 3.4 GHz 和 Visual Studio 2010 发布模式上，基准测试为：

x86

设想	时间（秒）
分支 - 随机数据	8.885
分支 - 排序数据	1.528
无分支 - 随机数据	3.716
无分支 - 排序数据	3.71

x64

设想	时间（秒）
分支 - 随机数据	11.302
分支 - 排序数据	1.830
无分支 - 随机数据	2.736
无分支 - 排序数据	2.737

结果在多次测试中是稳健的。当分支结果不可预测时，我们得到了很大的加速，但当它是可预测的时，我们会受到一点影响。事实上，当使用条件移动时，无论数据模式如何，性能都是相同的。

x86现在让我们通过调查它们生成的程序集来更仔细地观察。为简单起见，我们使用两个函数max1和max2。

max1使用条件分支if... else ...：

int max1(int a, int b) {
    if (a > b)
        return a;
    else
        return b;
}

max2使用三元运算符... ? ... : ...：

int max2(int a, int b) {
    return a > b ? a : b;
}

在 x86-64 机器上，GCC -S生成下面的程序集。

:max1
    movl    %edi, -4(%rbp)
    movl    %esi, -8(%rbp)
    movl    -4(%rbp), %eax
    cmpl    -8(%rbp), %eax
    jle     .L2
    movl    -4(%rbp), %eax
    movl    %eax, -12(%rbp)
    jmp     .L4
.L2:
    movl    -8(%rbp), %eax
    movl    %eax, -12(%rbp)
.L4:
    movl    -12(%rbp), %eax
    leave
    ret

:max2
    movl    %edi, -4(%rbp)
    movl    %esi, -8(%rbp)
    movl    -4(%rbp), %eax
    cmpl    %eax, -8(%rbp)
    cmovge  -8(%rbp), %eax
    leave
    ret