繁体   English   中英

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

Why is processing a sorted array faster than processing an unsorted array?

提示:本站收集StackOverFlow近2千万问答,支持中英文搜索,鼠标放在语句上弹窗显示对应的参考中文或英文, 本站还提供   中文繁体   英文版本   中英对照 版本,有任何建议请联系yoyou2525@163.com。

这是一段 C++ 代码,它显示了一些非常特殊的行为。 出于某种奇怪的原因,对数据进行排序(定时区域之前)奇迹般地使循环快了近六倍。

#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)
    {
        for (unsigned c = 0; c < arraySize; ++c)
        {   // Primary loop
            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';
}
  • 没有std::sort(data, data + arraySize); ,代码运行时间为 11.54 秒。
  • 使用排序后的数据,代码运行时间为 1.93 秒。

(排序本身比通过数组花费的时间更多,因此如果我们需要为未知数组计算它,实际上不值得这样做。)


最初,我认为这可能只是语言或编译器异常,所以我尝试了 Java:

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)
        {
            for (int c = 0; c < arraySize; ++c)
            {   // Primary loop
                if (data[c] >= 128)
                    sum += data[c];
            }
        }

        System.out.println((System.nanoTime() - start) / 1000000000.0);
        System.out.println("sum = " + sum);
    }
}

有类似但不太极端的结果。


我的第一个想法是排序将数据带入缓存,但后来我认为这是多么愚蠢,因为数组刚刚生成。

  • 到底是怎么回事?
  • 为什么处理排序数组比处理未排序数组更快?

该代码总结了一些独立的术语,因此顺序无关紧要。


关于不同/更高版本的编译器和选项的相同效果的相关/后续问答

27 个回复

您是分支预测失败的受害者。


什么是分支预测?

考虑一个铁路枢纽:

显示铁路枢纽的图片 图片来自 Mecanismo,来自 Wikimedia Commons。 CC-By-SA 3.0许可下使用。

现在为了争论,假设这是在 1800 年代 - 在长途或无线电通信之前。

你是一个路口的操作员,你听到一列火车驶来。 你不知道它应该走哪条路。 你停下火车问司机他们想要哪个方向。 然后你适当地设置开关。

火车很重,惯性很大,所以它们需要很长时间才能启动和减速。

有没有更好的办法? 你猜火车会往哪个方向走!

  • 如果你猜对了,它会继续。
  • 如果你猜错了,船长会停下来,后退,并大喊你拨动开关。 然后它可以从另一条路径重新启动。

如果你每次都猜对了,火车就永远不必停下来。
如果你经常猜错,火车会花很多时间停下来,倒车,再重新启动。


考虑一个 if 语句:在处理器级别,它是一条分支指令:

包含 if 语句的已编译代码的屏幕截图

你是一个处理器,你看到一个分支。 你不知道它会走哪条路。 你做什么工作? 您停止执行并等待前面的指令完成。 然后你继续沿着正确的路径前进。

现代处理器很复杂并且有很长的管道。 这意味着他们需要永远“热身”和“减速”。

有没有更好的办法? 你猜分支会往哪个方向走!

  • 如果你猜对了,你就继续执行。
  • 如果你猜错了,你需要刷新管道并回滚到分支。 然后你可以从另一条路径重新开始。

如果您每次都猜对了,则执行将永远不必停止。
如果您经常猜错,您将花费大量时间停止、回滚和重新启动。


这就是分支预测。 我承认这不是最好的类比,因为火车只能用旗子指示方向。 但是在计算机中,处理器直到最后一刻才知道一个分支将走向哪个方向。

您将如何战略性地猜测以最小化火车必须倒退并沿另一条路径行驶的次数? 你看看过去的历史! 如果火车 99% 的时间都向左行驶,那么您猜是向左行驶。 如果它交替,那么你改变你的猜测。 如果它每三遍一次,你猜也是一样的......

换句话说,您尝试识别一种模式并遵循它。 这或多或少是分支预测器的工作方式。

大多数应用程序都有行为良好的分支。 因此,现代分支预测器通常会达到 >90% 的命中率。 但是当面对没有可识别模式的不可预测的分支时,分支预测器实际上是无用的。

进一步阅读:维基百科上的“分支预测器”文章


正如上面所暗示的,罪魁祸首是这个 if 语句:

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

注意数据在0到255之间是均匀分布的。当数据排序后,大概前半部分的迭代不会进入if语句。 之后,他们都会进入if语句。

这对分支预测器非常友好,因为分支连续多次沿同一方向前进。 即使是一个简单的饱和计数器也能正确预测分支,除了它切换方向后的几次迭代。

快速可视化:

T = branch taken
N = branch not taken

data[] = 0, 1, 2, 3, 4, ... 126, 127, 128, 129, 130, ... 250, 251, 252, ...
branch = N  N  N  N  N  ...   N    N    T    T    T  ...   T    T    T  ...

       = NNNNNNNNNNNN ... NNNNNNNTTTTTTTTT ... TTTTTTTTTT  (easy to predict)

但是,当数据完全随机时,分支预测器就变得无用了,因为它无法预测随机数据。 因此可能会有大约 50% 的错误预测(不比随机猜测好)。

data[] = 226, 185, 125, 158, 198, 144, 217, 79, 202, 118,  14, 150, 177, 182, ...
branch =   T,   T,   N,   T,   T,   T,   T,  N,   T,   N,   N,   T,   T,   T  ...

       = TTNTTTTNTNNTTT ...   (completely random - impossible to predict)

可以做什么?

如果编译器无法将分支优化为有条件的移动,如果您愿意为了性能而牺牲可读性,您可以尝试一些技巧。

代替:

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

和:

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

这消除了分支并用一些按位运算替换它。

(请注意,此 hack 并不严格等同于原始 if 语句。但在这种情况下,它对data[]所有输入值都有效。)

基准:酷睿 i7 920 @ 3.5 GHz

C++ - Visual Studio 2010 - x64 版本

设想 时间(秒)
分支 - 随机数据 11.777
分支 - 排序数据 2.352
无分支 - 随机数据 2.564
Branchless - 排序数据 2.587

Java - NetBeans 7.1.1 JDK 7 - x64

设想 时间(秒)
分支 - 随机数据 10.93293813
分支 - 排序数据 5.643797077
无分支 - 随机数据 3.113581453
Branchless - 排序数据 3.186068823

观察:

  • 与分支:排序和未排序的数据之间存在巨大差异。
  • 使用 Hack:排序数据和未排序数据之间没有区别。
  • 在 C++ 的情况下,当数据被排序时,hack 实际上比分支慢一点。

一般的经验法则是避免关键循环中的数据相关分支(例如在本例中)。


更新:

  • 在 x64 上使用-O3-ftree-vectorize GCC 4.6.1 能够生成条件移动,因此排序和未排序数据之间没有区别 - 两者都很快。

    (或者有点快:对于已经排序的情况, cmov可能会更慢,特别是如果 GCC 将它放在关键路径上而不是仅仅add ,尤其是在 Broadwell 之前的 Intel 上,其中cmov有 2 个周期延迟: gcc 优化标志 -O3 使代码变慢比 -O2 )

  • 即使在/Ox下,VC++ 2010 也无法为此分支生成条件移动。

  • 英特尔 C++ 编译器(ICC) 11 做了一些神奇的事情。 交换两个循环,从而将不可预测的分支提升到外循环。 它不仅不受错误预测的影响,而且速度是 VC++ 和 GCC 生成的速度的两倍! 换句话说,ICC 利用测试循环来击败基准测试......

  • 如果您为英特尔编译器提供无分支代码,它会直接将其矢量化……并且与分支(使用循环交换)一样快。

这表明即使是成熟的现代编译器在优化代码的能力方面也会有很大差异......

分支预测。

对于已排序的数组,条件data[c] >= 128首先对于连续值是false ,然后对于所有后续值变为true 这很容易预测。 对于未排序的数组,您需要支付分支成本。

对数据进行排序时性能显着提高的原因是删除了分支预测惩罚,正如Mysticial 的回答中所解释的那样。

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

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

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

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
Branchless - 排序数据 3.71

x64

设想 时间(秒)
分支 - 随机数据 11.302
分支 - 排序数据 1.830
无分支 - 随机数据 2.736
Branchless - 排序数据 2.737

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

现在让我们通过研究它们生成的x86程序集来更仔细地观察。 为简单起见,我们使用两个函数max1max2

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

由于使用了指令cmovge max2使用的代码要少cmovge 但真正的好处是max2不涉及分支跳转jmp ,如果预测结果不正确,这将导致显着的性能损失。

那么为什么有条件的移动表现更好呢?

在典型的x86处理器中,一条指令的执行分为几个阶段。 粗略地说,我们有不同的硬件来处理不同的阶段。 因此,我们不必等待一条指令完成即可开始新的一条指令。 这称为流水线

在分支情况下,后面的指令是由前面的指令决​​定的,所以我们不能做流水线。 我们要么等待,要么预测。

在条件移动情况下,执行条件移动指令分为几个阶段,但较早的阶段如FetchDecode不依赖于前一条指令的结果; 只有后期需要结果。 因此,我们等待了一条指令执行时间的一小部分。 这就是为什么在预测容易时,条件移动版本比分支慢的原因。

Computer Systems: A Programmer's Perspective,第二版一书详细解释了这一点。 您可以查看第 3.6.6 节的条件移动指令,查看完整的第 4 章处理器体系结构,以及第 5.11.2 节中关于分支预测和错误预测惩罚的特殊处理。

有时,一些现代编译器可以将我们的代码优化为具有更好性能的程序集,有时一些编译器不能(有问题的代码使用 Visual Studio 的本机编译器)。 当场景变得如此复杂以至于编译器无法自动优化它们时,了解不可预测时分支和条件移动之间的性能差异可以帮助我们编写具有更好性能的代码。

如果您对可以对此代码进行的更多优化感到好奇,请考虑:

从原始循环开始:

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

通过循环交换,我们可以安全地将此循环更改为:

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

然后,您可以看到if条件在i循环的整个执行过程中保持不变,因此您可以将if提升出来:

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

然后,您会看到内部循环可以折叠为一个表达式,假设浮点模型允许(例如,抛出/fp:fast

for (unsigned j = 0; j < arraySize; ++j)
{
    if (data[j] >= 128)
    {
        sum += data[j] * 100000;
    }
}

那个比以前快100,000倍。

毫无疑问,我们中的一些人会对识别 CPU 分支预测器有问题的代码的方法感兴趣。 Valgrind 工具cachegrind有一个分支预测器模拟器,通过使用--branch-sim=yes标志启用。 在此问题中的示例上运行它,将外部循环的数量减少到 10000 并使用g++编译,得到以下结果:

排序:

==32551== Branches:        656,645,130  (  656,609,208 cond +    35,922 ind)
==32551== Mispredicts:         169,556  (      169,095 cond +       461 ind)
==32551== Mispred rate:            0.0% (          0.0%     +       1.2%   )

未分类:

==32555== Branches:        655,996,082  (  655,960,160 cond +  35,922 ind)
==32555== Mispredicts:     164,073,152  (  164,072,692 cond +     460 ind)
==32555== Mispred rate:           25.0% (         25.0%     +     1.2%   )

深入到cg_annotate生成的cg_annotate输出,我们看到了有问题的循环:

排序:

          Bc    Bcm Bi Bim
      10,001      4  0   0      for (unsigned i = 0; i < 10000; ++i)
           .      .  .   .      {
           .      .  .   .          // primary loop
 327,690,000 10,016  0   0          for (unsigned c = 0; c < arraySize; ++c)
           .      .  .   .          {
 327,680,000 10,006  0   0              if (data[c] >= 128)
           0      0  0   0                  sum += data[c];
           .      .  .   .          }
           .      .  .   .      }

未分类:

          Bc         Bcm Bi Bim
      10,001           4  0   0      for (unsigned i = 0; i < 10000; ++i)
           .           .  .   .      {
           .           .  .   .          // primary loop
 327,690,000      10,038  0   0          for (unsigned c = 0; c < arraySize; ++c)
           .           .  .   .          {
 327,680,000 164,050,007  0   0              if (data[c] >= 128)
           0           0  0   0                  sum += data[c];
           .           .  .   .          }
           .           .  .   .      }

这使您可以轻松识别有问题的行 - 在未排序的版本中, if (data[c] >= 128)行在 cachegrind 的分支预测模型下导致 164,050,007 个错误预测的条件分支( Bcm ),而在排序版本中仅导致 10,006 个.


或者,在 Linux 上,您可以使用性能计数器子系统来完成相同的任务,但使用 CPU 计数器获得本机性能。

perf stat ./sumtest_sorted

排序:

 Performance counter stats for './sumtest_sorted':

  11808.095776 task-clock                #    0.998 CPUs utilized          
         1,062 context-switches          #    0.090 K/sec                  
            14 CPU-migrations            #    0.001 K/sec                  
           337 page-faults               #    0.029 K/sec                  
26,487,882,764 cycles                    #    2.243 GHz                    
41,025,654,322 instructions              #    1.55  insns per cycle        
 6,558,871,379 branches                  #  555.455 M/sec                  
       567,204 branch-misses             #    0.01% of all branches        

  11.827228330 seconds time elapsed

未分类:

 Performance counter stats for './sumtest_unsorted':

  28877.954344 task-clock                #    0.998 CPUs utilized          
         2,584 context-switches          #    0.089 K/sec                  
            18 CPU-migrations            #    0.001 K/sec                  
           335 page-faults               #    0.012 K/sec                  
65,076,127,595 cycles                    #    2.253 GHz                    
41,032,528,741 instructions              #    0.63  insns per cycle        
 6,560,579,013 branches                  #  227.183 M/sec                  
 1,646,394,749 branch-misses             #   25.10% of all branches        

  28.935500947 seconds time elapsed

它还可以使用反汇编进行源代码注释。

perf record -e branch-misses ./sumtest_unsorted
perf annotate -d sumtest_unsorted
 Percent |      Source code & Disassembly of sumtest_unsorted
------------------------------------------------
...
         :                      sum += data[c];
    0.00 :        400a1a:       mov    -0x14(%rbp),%eax
   39.97 :        400a1d:       mov    %eax,%eax
    5.31 :        400a1f:       mov    -0x20040(%rbp,%rax,4),%eax
    4.60 :        400a26:       cltq   
    0.00 :        400a28:       add    %rax,-0x30(%rbp)
...

有关更多详细信息,请参阅性能教程

我刚刚阅读了这个问题及其答案,我觉得缺少答案。

我发现在托管语言中消除分支预测的一种常用方法是表查找而不是使用分支(尽管我没有在这种情况下测试它)。

这种方法通常适用于:

  1. 它是一个小表,很可能会缓存在处理器中,并且
  2. 您正在一个非常紧凑的循环中运行事物和/或处理器可以预加载数据。

背景和原因

从处理器的角度来看,您的内存很慢。 为了弥补速度上的差异,您的处理器中内置了几个缓存(L1/L2 缓存)。 所以想象一下,你正在做你漂亮的计算,并发现你需要一块内存。 处理器将获得它的“加载”操作并将内存块加载到缓存中——然后使用缓存来完成其余的计算。 由于内存相对较慢,这种“负载”会减慢您的程序速度。

与分支预测一样,这在奔腾处理器中得到了优化:处理器预测它需要加载一段数据并尝试在操作实际命中缓存之前将其加载到缓存中。 正如我们已经看到的,分支预测有时会出错——在最坏的情况下,你需要返回并实际等待内存加载,这将永远持续(换句话说:失败的分支预测是不好的,一个内存分支预测失败后的负载简直太可怕了! )。

对我们来说幸运的是,如果内存访问模式是可预测的,处理器会将其加载到其快速缓存中,一切都很好。

我们首先需要知道什么是 虽然通常越小越好,但经验法则是坚持使用大小小于等于 4096 字节的查找表。 作为上限:如果您的查找表大于 64K,则可能值得重新考虑。

构建表

所以我们发现我们可以创建一个小表。 接下来要做的是准备一个查找功能。 查找函数通常是使用几个基本整数运算(和、或、异或、移位、加、删除和可能是乘)的小函数。 您希望通过查找功能将您的输入转换为表格中的某种“唯一键”,然后它会简单地为您提供您希望它完成的所有工作的答案。

在这种情况下:>= 128 表示我们可以保留该值,< 128 表示我们摆脱它。 最简单的方法是使用“AND”:如果我们保留它,我们用 7FFFFFFF 将它与; 如果我们想去掉它,我们用 0 和它。还要注意 128 是 2 的幂——所以我们可以继续制作一个 32768/128 整数的表格,并用一个零和很多填充它7FFFFFFFF 的。

托管语言

您可能想知道为什么这在托管语言中运行良好。 毕竟,托管语言使用分支检查数组的边界,以确保您不会搞砸……

嗯,不完全是... :-)

在消除托管语言的这个分支方面已经做了很多工作。 例如:

for (int i = 0; i < array.Length; ++i)
{
   // Use array[i]
}

在这种情况下,编译器很明显永远不会满足边界条件。 至少 Microsoft JIT 编译器(但我希望 Java 做类似的事情)会注意到这一点并完全删除检查。 哇,这意味着没有分支。 同样,它将处理其他明显的情况。

如果您在使用托管语言进行查找时遇到麻烦——关键是在查找函数中添加& 0x[something]FFF以使边界检查可预测——并观察它进行得更快。

本案的结果

// Generate data
int arraySize = 32768;
int[] data = new int[arraySize];

Random random = new Random(0);
for (int c = 0; c < arraySize; ++c)
{
    data[c] = random.Next(256);
}

/*To keep the spirit of the code intact, I'll make a separate lookup table
(I assume we cannot modify 'data' or the number of loops)*/

int[] lookup = new int[256];

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

// Test
DateTime startTime = System.DateTime.Now;
long sum = 0;

for (int i = 0; i < 100000; ++i)
{
    // Primary loop
    for (int j = 0; j < arraySize; ++j)
    {
        /* Here you basically want to use simple operations - so no
        random branches, but things like &, |, *, -, +, etc. are fine. */
        sum += lookup[data[j]];
    }
}

DateTime endTime = System.DateTime.Now;
Console.WriteLine(endTime - startTime);
Console.WriteLine("sum = " + sum);
Console.ReadLine();

当数据被从0到255之间分布当数组进行排序,围绕迭代的第一半不会进入if语句来(在if语句下面共享)。

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

问题是:是什么使上述语句在某些情况下(如排序数据)不执行? 这里是“分支预测器”。 分支预测器是一种数字电路,它试图在确定之前猜测分支(例如, if-then-else结构)将走哪条路。 分支预测器的目的是改善指令流水线中的流程。 分支预测器在实现高效性能方面发挥着关键作用!

让我们做一些基准测试以更好地理解它

if语句的性能取决于其条件是否具有可预测的模式。 如果条件始终为真或始终为假,则处理器中的分支预测逻辑将选取该模式。 另一方面,如果模式不可预测,则if语句的开销会大得多。

让我们用不同的条件来衡量这个循环的性能:

for (int i = 0; i < max; i++)
    if (condition)
        sum++;

以下是具有不同真假模式的循环时间:

Condition                Pattern             Time (ms)
-------------------------------------------------------
(i & 0×80000000) == 0    T repeated          322

(i & 0xffffffff) == 0    F repeated          276

(i & 1) == 0             TF alternating      760

(i & 3) == 0             TFFFTFFF…           513

(i & 2) == 0             TTFFTTFF…           1675

(i & 4) == 0             TTTTFFFFTTTTFFFF…   1275

(i & 8) == 0             8T 8F 8T 8F …       752

(i & 16) == 0            16T 16F 16T 16F …   490

”真假模式可以使if语句比“”模式慢六倍! 当然,哪种模式好哪个不好取决于编译器生成的确切指令和特定处理器。

所以分支预测对性能的影响是毋庸置疑的!

避免分支预测错误的一种方法是构建查找表,并使用数据对其进行索引。 Stefan de Bruijn 在他的回答中讨论了这个问题。

但在这种情况下,我们知道值在 [0, 255] 范围内,我们只关心值 >= 128。这意味着我们可以轻松提取一个位来告诉我们我们是否想要一个值:通过移位数据向右7位,我们剩下0位或1位,我们只想在我们有1位时添加值。 让我们称这个位为“决定位”。

通过使用决策位的 0/1 值作为数组的索引,我们可以编写代码,无论数据是否排序,都同样快。 我们的代码总是会添加一个值,但是当决策位为 0 时,我们会在我们不关心的地方添加该值。 这是代码:

// Test
clock_t start = clock();
long long a[] = {0, 0};
long long sum;

for (unsigned i = 0; i < 100000; ++i)
{
    // Primary loop
    for (unsigned c = 0; c < arraySize; ++c)
    {
        int j = (data[c] >> 7);
        a[j] += data[c];
    }
}

double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
sum = a[1];

此代码浪费了一半的添加,但从未发生分支预测失败。 它在随机数据上比使用实际 if 语句的版本快得多。

但是在我的测试中,显式查找表比这稍快,可能是因为对查找表进行索引比位移位稍快。 这显示了我的代码如何设置和使用查找表(在代码中毫无想象力地将“查找表”称为lut )。 这是 C++ 代码:

// Declare and then fill in the lookup table
int lut[256];
for (unsigned c = 0; c < 256; ++c)
    lut[c] = (c >= 128) ? c : 0;

// Use the lookup table after it is built
for (unsigned i = 0; i < 100000; ++i)
{
    // Primary loop
    for (unsigned c = 0; c < arraySize; ++c)
    {
        sum += lut[data[c]];
    }
}

在这种情况下,查找表只有 256 字节,因此它非常适合缓存并且一切都很快。 如果数据是 24 位值,而我们只想要其中的一半,这种技术就不会很好地工作……查找表将太大而无法实用。 另一方面,我们可以结合上面显示的两种技术:首先移动位,然后索引查找表。 对于我们只需要上半值的 24 位值,我们可能会将数据右移 12 位,并保留 12 位值作为表索引。 12 位表索引意味着一个包含 4096 个值的表,这可能是实用的。

索引数组的技术,而不是使用if语句,可用于决定使用哪个指针。 我看到了一个实现二叉树的库,而不是有两个命名指针( pLeftpRight或其他), pRight有一个长度为 2 的指针数组,并使用“决策位”技术来决定要遵循哪一个。 例如,而不是:

if (x < node->value)
    node = node->pLeft;
else
    node = node->pRight;

这个库会做类似的事情:

i = (x < node->value);
node = node->link[i];

这是此代码的链接: Red Black Trees , Eternally Confuzzled

在排序的情况下,您可以比依赖成功的分支预测或任何无分支比较技巧做得更好:完全删除分支。

事实上,该数组被分区在一个连续的区域中, data < 128和另一个data >= 128 因此,您应该使用二分搜索(使用Lg(arraySize) = 15比较)找到分区点,然后从该点进行直接累加。

类似(未选中)

int i= 0, j, k= arraySize;
while (i < k)
{
  j= (i + k) >> 1;
  if (data[j] >= 128)
    k= j;
  else
    i= j;
}
sum= 0;
for (; i < arraySize; i++)
  sum+= data[i];

或者,稍微更混淆

int i, k, j= (i + k) >> 1;
for (i= 0, k= arraySize; i < k; (data[j] >= 128 ? k : i)= j)
  j= (i + k) >> 1;
for (sum= 0; i < arraySize; i++)
  sum+= data[i];

一种更快的方法,它给出了排序或未排序的近似解: sum= 3137536; (假设一个真正均匀的分布,16384 个样本的期望值为 191.5) :-)

由于分支预测,上述行为正在发生。

要了解分支预测,首先必须了解指令流水线

任何指令都被分解为一系列步骤,以便可以并行并行执行不同的步骤。 这种技术称为指令流水线,用于提高现代处理器的吞吐量。 为了更好地理解这一点,请参阅维基百科上的这个例子

通常,现代处理器有很长的管道,但为了方便起见,我们只考虑这 4 个步骤。

  1. IF——从内存中获取指令
  2. ID——解码指令
  3. EX——执行指令
  4. WB——写回CPU寄存器

4 级流水线一般用于 2 条指令。一般为 4 级流水线

回到上面的问题,让我们考虑以下说明:

                        A) if (data[c] >= 128)
                                /\
                               /  \
                              /    \
                        true /      \ false
                            /        \
                           /          \
                          /            \
                         /              \
              B) sum += data[c];          C) for loop or print().

如果没有分支预测,将发生以下情况:

要执行指令 B 或指令 C,处理器必须等到指令 A 没有到达流水线中的 EX 阶段,因为执行指令 B 或指令 C 的决定取决于指令 A 的结果。因此流水线看起来像这样。

当 if 条件返回 true 时:在此处输入图片说明

当 if 条件返回 false 时:在此处输入图片说明

由于等待指令A的结果,在上述情况下(没有分支预测;对于true和false)花费的总CPU周期为7。

那么什么是分支预测?

分支预测器将尝试在确定之前猜测分支(if-then-else 结构)将走哪条路。 它不会等待指令 A 到达流水线的 EX 阶段,而是会猜测决策并转到该指令(在我们的示例中为 B 或 C)。

如果猜测正确,管道看起来像这样:在此处输入图片说明

如果稍后检测到猜测是错误的,则丢弃部分执行的指令并且流水线以正确的分支重新开始,从而导致延迟。 在分支预测错误的情况下浪费的时间等于从获取阶段到执行阶段的流水线中的阶段数。 现代微处理器往往具有相当长的流水线,因此误预测延迟在 10 到 20 个时钟周期之间。 管道越长,就越需要一个好的分支预测器

在OP的代码中,第一次有条件时,分支预测器没有任何信息来建立预测,所以第一次它会随机选择下一条指令。 在 for 循环的后面,它可以根据历史进行预测。 对于按升序排序的数组,有三种可能:

  1. 所有元素都小于128
  2. 所有元素都大于128
  3. 一些起始的新元素小于 128,后来它变得大于 128

让我们假设预测器在第一次运行时总是假设真正的分支。

因此,在第一种情况下,它将始终采用真正的分支,因为从历史上看,它的所有预测都是正确的。 在第二种情况下,最初它会预测错误,但经过几次迭代后,它会正确预测。 在第 3 种情况下,它最初会正确预测,直到元素小于 128。之后它会失败一段时间,并在历史记录中看到分支预测失败时自行纠正。

在所有这些情况下,失败的次数都会太少,因此,只有几次需要丢弃部分执行的指令并从正确的分支重新开始,从而减少 CPU 周期。

但是在随机未排序数组的情况下,预测将需要丢弃部分执行的指令并在大多数情况下从正确的分支重新开始,与排序数组相比会导致更多的 CPU 周期。

官方回答来自

  1. 英特尔 - 避免分支预测错误的成本
  2. 英特尔 - 分支和循环重组以防止错误预测
  3. 科学论文-分支预测计算机体系结构
  4. 书籍:JL Hennessy,DA Patterson:计算机体系结构:定量方法
  5. 科学出版物中的文章:TY Yeh、YN Patt 在分支预测方面做了很多。

您还可以从这个可爱的图表中看出为什么分支预测器会感到困惑。

2位状态图

原码中的每个元素都是一个随机值

data[c] = std::rand() % 256;

所以预测器会随着std::rand()打击而改变方向。

另一方面,一旦排序,预测器将首先进入强烈不采用的状态,当值变为高值时,预测器将在三个运行过程中从强烈不采用到强烈采用。


在同一行中(我认为任何答案都没有强调这一点)很高兴提到有时(特别是在性能很重要的软件中 - 例如在 Linux 内核中)您可以找到一些 if 语句,如下所示:

if (likely( everything_is_ok ))
{
    /* Do something */
}

或类似:

if (unlikely(very_improbable_condition))
{
    /* Do something */    
}

likely()unlikely()实际上是通过使用类似 GCC 的__builtin_expect类的东西定义的宏,以帮助编译器插入预测代码以支持条件,同时考虑到用户提供的信息。 GCC 支持其他内置程序,这些内置程序可以更改正在运行的程序的行为或发出低级指令,例如清除缓存等。请参阅介绍可用 GCC 内置程序的文档

通常,这种优化主要存在于硬实时应用程序或嵌入式系统中,其中执行时间很重要且至关重要。 例如,如果您正在检查某些仅发生 1/10000000 次的错误条件,那么为什么不通知编译器呢? 这样,默认情况下,分支预测会假设条件为假。

C++ 中经常使用的布尔运算会在编译后的程序中产生许多分支。 如果这些分支在循环内部并且难以预测,它们会显着降低执行速度。 布尔变量存储为 8 位整数,值为0表示false ,值为1表示true

布尔变量是超定的,因为所有将布尔变量作为输入的运算符都会检查输入是否具有除01之外的任何其他值,但将布尔变量作为输出的运算符不能产生除01之外的任何其他值。 这使得使用布尔变量作为输入的操作效率低于必要。 考虑示例:

bool a, b, c, d;
c = a && b;
d = a || b;

这通常由编译器通过以下方式实现:

bool a, b, c, d;
if (a != 0) {
    if (b != 0) {
        c = 1;
    }
    else {
        goto CFALSE;
    }
}
else {
    CFALSE:
    c = 0;
}
if (a == 0) {
    if (b == 0) {
        d = 0;
    }
    else {
        goto DTRUE;
    }
}
else {
    DTRUE:
    d = 1;
}

此代码远非最佳。 如果预测错误,分支可能需要很长时间。 如果可以确定地知道操作数除了01之外没有其他值,那么布尔运算可以变得更加高效。 编译器之所以不做这样的假设是因为如果变量未初始化或来自未知来源,它们可能具有其他值。 如果ab已初始化为有效值,或者它们来自产生布尔输出的运算符,则可以优化上述代码。 优化后的代码如下所示:

char a = 0, b = 1, c, d;
c = a & b;
d = a | b;

char而不是bool是为了可以使用按位运算符( &| )而不是布尔运算符( &&|| )。 按位运算符是单条指令,只需要一个时钟周期。 即使ab值不是01 ,OR 运算符 ( | ) 也能工作。 如果操作数的值不是01 ,则 AND 运算符 ( & ) 和 EXCLUSIVE OR 运算符 ( ^ ) 可能会给出不一致的结果。

~不能用于 NOT。 相反,您可以通过与1异或来对已知为01的变量进行布尔值 NOT 运算:

bool a, b;
b = !a;

可以优化为:

char a = 0, b;
b = a ^ 1;

a && b不能用a & b替换,如果b是一个表达式,如果afalse则不应计算( &&不会计算b&会)。 同样, a || b a || b不能用a | b代替a | b a | b如果b是一个表达式,如果atrue ,则不应计算该表达式。

如果操作数是变量,则使用按位运算符比操作数是比较更有利:

bool a; double x, y, z;
a = x > y && z < 5.0;

在大多数情况下是最佳的(除非您期望&&表达式会产生许多分支错误预测)。

这是肯定的!...

由于代码中发生的切换,分支预测会使逻辑运行速度变慢! 这就像你要走一条直街或一条有很多转弯的街道,肯定会更快地完成直行!...

如果数组已排序,则您的条件在第一步为假: data[c] >= 128 ,然后在到街道尽头的整个过程中变为真值。 这就是你如何更快地到达逻辑的末尾。 另一方面,使用未排序的数组,您需要进行大量的转换和处理,这肯定会使您的代码运行速度变慢...

看看我在下面为你创建的图像。 哪条街会更快完工?

分支预测

所以以编程方式,分支预测会导致过程变慢......

最后,很高兴知道我们有两种分支预测,每种预测都会以不同的方式影响您的代码:

1. 静态

2.动态

分支预测

微处理器在第一次遇到条件分支时使用静态分支预测,动态分支预测用于条件分支代码的后续执行。

为了有效地编写代码以利用这些规则,在编写if-elseswitch语句时,首先检查最常见的情况,然后逐步减少到最不常见的情况。 对于静态分支预测,循环不一定需要任何特殊的代码排序,因为通常只使用循环迭代器的条件。

这个问题已经多次得到很好的回答。 我仍然想提请小组注意另一个有趣的分析。

最近这个例子(稍微修改了)也被用作一种方式来演示如何在 Windows 上的程序本身中分析一段代码。 在此过程中,作者还展示了如何使用结果来确定代码在排序和未排序的情况下花费大部分时间的地方。 最后,这篇文章还展示了如何使用 HAL(硬件抽象层)的一个鲜为人知的功能来确定在未排序的情况下发生了多少分支预测错误。

链接在这里: 自我剖析的演示

正如其他人已经提到的,神秘的背后是分支预测器

我不是想添加一些东西,而是以另一种方式解释这个概念。 wiki 上有一个简洁的介绍,其中包含文本和图表。 我喜欢下面的解释,它使用图表直观地阐述了分支预测器。

在计算机体系结构中,分支预测器是一个数字电路,它试图在确定之前猜测分支(例如,if-then-else 结构)将走向何方。 分支预测器的目的是改善指令流水线中的流程。 分支预测器在许多现代流水线微处理器架构(如 x86)中实现高效性能方面发挥着关键作用。

双向转移通常用条件跳转指令来实现。 条件跳转可以“不采用”并继续执行紧跟在条件跳转之后的第一个代码分支,也可以“采用”并跳转到程序存储器中第二个代码分支所在的不同位置存储。 在计算条件并且条件跳转已经通过指令流水线中的执行阶段之前,不确定是否进行条件跳转(参见图 1)。

图1

基于所描述的场景,我编写了一个动画演示来展示在不同情况下如何在管道中执行指令。

  1. 没有分支预测器。

如果没有分支预测,处理器将不得不等到条件跳转指令通过执行阶段,然后下一条指令才能进入流水线中的提取阶段。

该示例包含三个指令,第一个是条件跳转指令。 后两条指令可以进入流水线,直到条件跳转指令执行完毕。

没有分支预测器

完成3条指令需要9个时钟周期。

  1. 使用分支预测器,不要进行条件跳转。 让我们假设预测没有进行条件跳转。

在此处输入图片说明

完成3条指令需要7个时钟周期。

  1. 使用分支预测器并进行条件跳转。 让我们假设预测没有进行条件跳转。

在此处输入图片说明

完成3条指令需要9个时钟周期。

在分支预测错误的情况下浪费的时间等于从获取阶段到执行阶段的流水线中的阶段数。 现代微处理器往往具有相当长的流水线,因此误预测延迟在 10 到 20 个时钟周期之间。 因此,延长流水线会增加对更高级分支预测器的需求。

如您所见,我们似乎没有理由不使用 Branch Predictor。

这是一个非常简单的演示,阐明了 Branch Predictor 的基本部分。 如果这些 gif 很烦人,请随时从答案中删除它们,访问者还可以从BranchPredictorDemo获取实时演示源代码

分支预测增益!

重要的是要了解分支错误预测不会减慢程序的速度。 错过预测的代价就像分支预测不存在一样,您等待表达式的评估来决定要运行的代码(下一段中的进一步解释)。

if (expression)
{
    // Run 1
} else {
    // Run 2
}

每当有if-else \\ switch语句时,就必须对表达式求值以确定应该执行哪个块。 在编译器生成的汇编代码中,插入了条件分支指令。

分支指令可以导致计算机开始执行不同的指令序列,从而偏离其根据某些条件按顺序执行指令的默认行为(即,如果表达式为假,则程序跳过if块的代码),这是我们案例中的表达式评估。

话虽如此,编译器会尝试在实际评估结果之前预测结果。 它将从if块中获取指令,如果表达式结果为真,那就太好了! 我们获得了评估它的时间并在代码中取得了进展; 如果不是,那么我们正在运行错误的代码,管道被刷新,并运行正确的块。

可视化:

假设您需要选择路线 1 或路线 2。 等待您的合作伙伴查看地图,您已在 ## 处停下并等待,或者您可以选择路线 1,如果幸运的话(路线 1 是正确的路线),那就太好了,您不必等待您的合作伙伴查看地图(您节省了他查看地图所需的时间),否则您只需返回即可。

虽然冲洗管道的速度非常快,但如今进行这场赌博是值得的。 预测排序数据或缓慢变化的数据总是比预测快速变化更容易和更好。

 O      Route 1  /-------------------------------
/|\             /
 |  ---------##/
/ \            \
                \
        Route 2  \--------------------------------

在 ARM 上,不需要分支,因为每条指令都有一个 4 位条件字段,它测试(以零成本)处理器状态寄存器中可能出现的16 种不同条件中的任何一种,以及指令的条件是否为false,则跳过该指令。 这消除了对短分支的需要,并且该算法不会有分支预测命中。 因此,由于排序的额外开销,此算法的排序版本将比 ARM 上的未排序版本运行得慢。

该算法的内部循环在 ARM 汇编语言中类似于以下内容:

MOV R0, #0   // R0 = sum = 0
MOV R1, #0   // R1 = c = 0
ADR R2, data // R2 = addr of data array (put this instruction outside outer loop)
.inner_loop  // Inner loop branch label
    LDRB R3, [R2, R1]   // R3 = data[c]
    CMP R3, #128        // compare R3 to 128
    ADDGE R0, R0, R3    // if R3 >= 128, then sum += data[c] -- no branch needed!
    ADD R1, R1, #1      // c++
    CMP R1, #arraySize  // compare c to arraySize
    BLT inner_loop      // Branch to inner_loop if c < arraySize

但这实际上是更大图景的一部分:

CMP操作码总是更新处理器状态寄存器 (PSR) 中的状态位,因为这是它们的目的,但大多数其他指令不会触及 PSR,除非您向指令添加可选的S后缀,指定 PSR 应基于根据指令的结果。 就像 4 位条件后缀一样,能够在不影响 PSR 的情况下执行指令是一种机制,在 ARM 上减少了分支的需要,也有利于硬件层面的乱序调度,因为在执行一些更新的操作之后 X状态位,随后(或并行)您可以执行一系列其他明确不应影响(或受其影响)状态位的工作,然后您可以测试 X 之前设置的状态位的状态。

条件测试字段和可选的“设置状态位”字段可以组合,例如:

  • ADD R1, R2, R3执行R1 = R2 + R3而不更新任何状态位。
  • 仅当影响状态位的前一条指令导致大于或等于条件时ADDGE R1, R2, R3执行相同的操作。
  • ADDS R1, R2, R3执行加法,然后根据结果是负数、零、进位(无符号加法)还是溢出(有符号加法)更新处理器状态寄存器中的NZCV标志.
  • ADDSGE R1, R2, R3仅在GE测试为真时才执行加法,然后根据加法结果更新状态位。

大多数处理器架构没有这种能力来指定是否应该为给定的操作更新状态位,这可能需要编写额外的代码来保存和稍后恢复状态位,或者可能需要额外的分支,或者可能会限制处理器的输出订单执行效率:大多数 CPU 指令集架构在大多数指令之后强制更新状态位的副作用之一是,很难区分哪些指令可以并行运行而不会相互干扰。 更新状态位有副作用,因此对代码有线性化影响。 ARM 在任何指令上混合和匹配无分支条件测试以及在任何指令之后更新或不更新状态位的选项的能力非常强大,对于汇编语言程序员和编译器来说,并生成非常有效的代码。

当您不必分支时,您可以避免为短分支而刷新管道的时间成本,并且您可以避免多种形式的推测评估的设计复杂性。 针对许多最近发现的处理器漏洞(Spectre 等)的缓解措施的初始初始实现对性能的影响向您展示了现代处理器的性能在多大程度上取决于复杂的推测评估逻辑。 凭借较短的流水线和显着减少的分支需求,ARM 不需要像 CISC 处理器那样依赖推测性评估。 (当然,高端 ARM 实现确实包括推测性评估,但这只是性能故事的一小部分。)

如果您想知道为什么 ARM 如此成功,那么这两种机制的出色效率和相互作用(与另一种机制相结合,可以让您“桶移”任何算术运算符的两个参数中的一个或偏移内存访问零额外成本的运算符)是故事的重要组成部分,因为它们是 ARM 架构效率的最大来源。 1983 年 ARM ISA 的原始设计师 Steve Furber 和 Roger(现为 Sophie)Wilson 的才华不容小觑。

这是关于分支预测。 它是什么?

  • 分支预测器是一种古老的性能改进技术,在现代架构中仍然具有相关性。 虽然简单的预测技术提供了快速的查找和功率效率,但它们的误预测率很高。

  • 另一方面,复杂的分支预测——无论是基于神经的还是两级分支预测的变体——提供更好的预测准确性,但它们消耗更多的能量,复杂性呈指数级增长。

  • 除此之外,在复杂的预测技术中,预测分支所花费的时间本身就非常高——从 2 到 5 个周期不等——这与实际分支的执行时间相当。

  • 分支预测本质上是一个优化(最小化)问题,其重点在于以最少的资源实现尽可能低的未命中率、低功耗和低复杂度。

确实存在三种不同的分支:

前向条件分支- 基于运行时条件,PC(程序计数器)更改为指向指令流中的前向地址。

向后条件分支- PC 更改为在指令流中向后指向。 分支基于某些条件,例如当循环结束时的测试指出应该再次执行循环时,向后分支到程序循环的开头。

无条件分支- 这包括没有特定条件的跳转、过程调用和返回。 例如,无条件跳转指令可能用汇编语言简单地编码为“jmp”,指令流必须立即定向到跳转指令所指向的目标位置,而条件跳转可能被编码为“jmpne”只有在先前“比较”指令中两个值的比较结果显示值不相等时,才会重定向指令流。 (x86 架构使用的分段寻址方案增加了额外的复杂性,因为跳转可以是“近”(段内)或“远”(段外)。每种类型对分支预测算法都有不同的影响。)

静态/动态分支预测:微处理器在第一次遇到条件分支时使用静态分支预测,动态分支预测用于条件分支代码的后续执行。

参考:

除了分支预测可能会减慢你的速度之外,排序数组还有另一个优点:

您可以有一个停止条件,而不仅仅是检查值,这样您就可以只循环相关数据,而忽略其余部分。
分支预测只会错过一次。

 // sort backwards (higher values first), may be in some other part of the code
 std::sort(data, data + arraySize, std::greater<int>());

 for (unsigned c = 0; c < arraySize; ++c) {
       if (data[c] < 128) {
              break;
       }
       sum += data[c];               
 }

由于称为分支预测的现象,排序数组的处理速度比未排序数组快。

分支预测器是一个数字电路(在计算机体系结构中),它试图预测分支将走向何方,从而改善指令流水线中的流程。 电路/计算机预测下一步并执行它。

做出错误的预测会导致返回上一步,并执行另一个预测。 假设预测正确,代码将继续下一步。 错误的预测会导致重复相同的步骤,直到发生正确的预测。

你的问题的答案很简单。

在未排序的数组中,计算机会进行多次预测,导致出错的机会增加。 而在排序数组中,计算机做出的预测较少,从而降低了出错的机会。 做出更多预测需要更多时间。

排序数组:直道

____________________________________________________________________________________
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

未排序数组:弯曲的道路

______   ________
|     |__|

分支预测:猜测/预测哪条路是直的,不检查就跟随它

___________________________________________ Straight road
 |_________________________________________|Longer road

虽然两条路都到达同一个目的地,但直路较短,另一条较长。 如果那时你错误地选择了另一个,就没有回头路了,所以如果你选择了更长的路,你会浪费一些额外的时间。 这与计算机中发生的情况类似,我希望这有助于您更好地理解。


我还想从评论中引用@Simon_Weaver

它不会做出更少的预测——它会做出更少的错误预测。 它仍然必须通过循环对每次进行预测......

我在 MacBook Pro(Intel i7,64 位,2.4 GHz)上使用 MATLAB 2011b 尝试了相同的代码,用于以下 MATLAB 代码:

% Processing time with Sorted data vs unsorted data
%==========================================================================
% Generate data
arraySize = 32768
sum = 0;
% Generate random integer data from range 0 to 255
data = randi(256, arraySize, 1);


%Sort the data
data1= sort(data); % data1= data  when no sorting done


%Start a stopwatch timer to measure the execution time
tic;

for i=1:100000

    for j=1:arraySize

        if data1(j)>=128
            sum=sum + data1(j);
        end
    end
end

toc;

ExeTimeWithSorting = toc - tic;

上述MATLAB代码的结果如下:

  a: Elapsed time (without sorting) = 3479.880861 seconds.
  b: Elapsed time (with sorting ) = 2377.873098 seconds.

在@GManNickG 中的 C 代码的结果我得到:

  a: Elapsed time (without sorting) = 19.8761 sec.
  b: Elapsed time (with sorting ) = 7.37778 sec.

基于此,看起来 MATLAB 几乎比没有排序的 C 实现慢175 倍,而排序则慢350 倍 换句话说,(分支预测的)效果对于 MATLAB 实现是1.46,对于 C 实现是2.7 倍

其他答案认为需要对数据进行排序的假设是不正确的。

下面的代码不会对整个数组进行排序,而是只对它的 200 个元素段进行排序,因此运行速度最快。

仅对 k 元素部分进行排序可在线性时间O(n)完成预处理,而不是对整个数组进行排序所需的O(n.log(n))时间。

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

int main() {
    int data[32768]; const int l = sizeof data / sizeof data[0];

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

    // sort 200-element segments, not the whole array
    for (unsigned c = 0; c + 200 <= l; c += 200)
        std::sort(&data[c], &data[c + 200]);

    clock_t start = clock();
    long long sum = 0;

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

    std::cout << static_cast<double>(clock() - start) / CLOCKS_PER_SEC << std::endl;
    std::cout << "sum = " << sum << std::endl;
}

这也“证明”它与排序顺序等任何算法问题无关,确实是分支预测。

Bjarne Stroustrup对这个问题的回答

这听起来像是一个面试问题。 这是真的吗? 你怎么知道的? 在没有先进行一些测量的情况下回答有关效率的问题是一个坏主意,因此知道如何测量很重要。

所以,我尝试使用一百万个整数的向量并得到:

Already sorted    32995 milliseconds
Shuffled          125944 milliseconds

Already sorted    18610 milliseconds
Shuffled          133304 milliseconds

Already sorted    17942 milliseconds
Shuffled          107858 milliseconds

我跑了几次以确定。 是的,这种现象是真实的。 我的关键代码是:

void run(vector<int>& v, const string& label)
{
    auto t0 = system_clock::now();
    sort(v.begin(), v.end());
    auto t1 = system_clock::now();
    cout << label
         << duration_cast<microseconds>(t1 — t0).count()
         << " milliseconds\n";
}

void tst()
{
    vector<int> v(1'000'000);
    iota(v.begin(), v.end(), 0);
    run(v, "already sorted ");
    std::shuffle(v.begin(), v.end(), std::mt19937{ std::random_device{}() });
    run(v, "shuffled    ");
}

至少这个编译器、标准库和优化器设置的现象是真实的。 不同的实现可以而且确实给出了不同的答案。 事实上,有人做了更系统的研究(快速网络搜索会找到它)并且大多数实现都显示了这种效果。

原因之一是分支预测:排序算法中的关键操作是“if(v[i] < pivot]) …”或等价的。 对于排序的序列,测试总是正确的,而对于随机序列,选择的分支随机变化。

另一个原因是当向量已经排序时,我们永远不需要将元素移动到正确的位置。 这些小细节的影响是我们看到的五六分之一。

快速排序(以及一般的排序)是一项复杂的研究,它吸引了一些计算机科学最伟大的思想家。 一个好的排序函数是选择好的算法和在实现过程中注意硬件性能的结果。

如果你想写出高效的代码,你需要对机器架构有所了解。

这个问题源于 CPU 上的分支预测模型 我建议阅读这篇论文:

通过多分支预测和分支地址缓存提高指令提取率

当您对元素进行排序后, IR就不会费心一次又一次地获取所有 CPU 指令。 它从缓存中获取它们。

这是一段C ++代码,显示了一些非常特殊的行为。 出于某些奇怪的原因,奇迹般地对数据进行排序使代码快了将近六倍:

#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;
}
  • 没有std::sort(data, data + arraySize); ,代码将在11.54秒内运行。
  • 使用排序的数据,代码将在1.93秒内运行。

最初,我认为这可能只是语言或编译器异常,所以我尝试了Java:

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);
    }
}

具有相似但不太极端的结果。


我首先想到的是排序将数据带入缓存,但是后来我想到这样做是多么愚蠢,因为刚刚生成了数组。

  • 到底是怎么回事?
  • 为什么处理排序数组要比处理未排序数组快?

该代码总结了一些独立的术语,因此顺序无关紧要。

分支预测

这称为分支预测 如果没有分支预测,处理器将不得不等到条件跳转指令通过执行阶段,然后下一条指令才能进入流水线中的提取阶段。 分支预测器试图通过尝试猜测是否最有可能采用或不采用条件跳转来避免这种时间浪费。 然后被猜测为最可能的分支被提取并推测性地执行。 如果稍后检测到猜测是错误的,则推测性地执行,导致延迟。

data[c] >= 128

从这个链接获得更多帮助: Multiple Branch Prediction for Wide-Issue Superscalar

这个概念叫做分支预测

分支预测是一种优化技术,它在确定代码之前预测代码将采用的路径。 这很重要,因为在代码执行期间,机器会预取几个代码语句并将它们存储在管道中。

问题出现在条件分支中,其中有两个可能的路径或代码部分可以执行。

当预测为真时,优化技术就成功了。

当预测错误时,简单解释一下,存储在管道中的代码语句被证明是错误的,而必须完全重新加载实际代码,这会占用大量时间。

正如常识所暗示的那样,对已排序事物的预测比对未排序事物的预测准确得多。

分支预测可视化:

排序
排序 未分类未分类

正如我前面有很多人提到的那样,有很多细节; 但是,简单来说如下

可以较早地做出决定,例如搜索一个数字,在这种情况下,如果您要查找的num比数组中存在的数少,那么由于对数组进行了排序,因此可以消除一半的搜索将是O(1/2)。

顺便说一句,正如任何人都会注意到的那样,以上行为是与语言无关的,我的意思是,总是会有更少的指令被执行,因此时间更快。

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

代码示例:

// CPP program to demonstrate processing
// time of sorted and unsorted array
#include <iostream>
#include <algorithm>
#include <ctime>
using namespace std;

const int N = 100001;

int main()
{
    int arr[N];

    // Assign random values to array
    for (int i=0; i<N; i++)
        arr[i] = rand()%N;

    // for loop for unsorted array
    int count = 0;
    double start = clock();
    for (int i=0; i<N; i++)
        if (arr[i] < N/2)
            count++;

    double end = clock();
    cout << "Time for unsorted array :: "
        << ((end - start)/CLOCKS_PER_SEC)
        << endl;
    sort(arr, arr+N);

    // for loop for sorted array
    count = 0;
    start = clock();

    for (int i=0; i<N; i++)
        if (arr[i] < N/2)
            count++;

    end = clock();
    cout << "Time for sorted array :: "
        << ((end - start)/CLOCKS_PER_SEC)
        << endl;

    return 0;
}

执行时间:

执行时间

结论:

请注意,与未排序数组相比,处理排序数组所需的时间更少。 对排序数组进行这种优化的原因是分支预测。

什么是分支预测?

计算机体系结构中的分支预测侧重于确定程序指令管道中的条件分支(跳转)是否可能被采用。 因为他们必须在执行当前指令之前猜测要获取的地址字段,所以所有流水线处理器都以某种方式进行分支预测。

分支预测如何不适用于上述情况?

if 条件检查 arr[i] < 5000,但如果您观察排序数组的情况,则在传递数字 5000 后,条件始终为假,在此之前,始终为真。 CPU 将识别该模式并能够正确预测在条件分支之后接下来要执行的指令,而不是有时在猜测错误后不得不倒带。

分支预测算法的工作:

分支预测适用于算法遵循的模式或基本上是历史,它是如何在前面的步骤中执行的。 如果猜测正确,则 CPU 继续执行,如果出错,则 CPU 需要刷新管道并回滚到分支并从头重新启动。

示例 2:想想电话簿

所有名称都已排序。 在书中寻找“约翰逊”。 我敢打赌,这将花费您不到 3 分钟的时间。 正如您知道 J 在字母表中的位置,现在假设您有 60,000 个相同的姓名和电话号码 - 在同一类型的书中未分类,全部混在一起。 现在没有特别的顺序,去书里找约翰逊吧。 我敢打赌这需要你几个小时! 它可能在第 3 页或第 349 页; 你永远不知道它在哪里。

在 C++ 中,由于分支预测,处理排序数组比处理未排序数组更快。 在计算机体系结构中,分支预测确定程序指令流中的条件分支(跳转)是否可能被采用。

让我们举个例子 -

if(arr[i] > 50) {
   Do some operation B
} else {
   Do some operation A
}

如果我们以未排序和排序的顺序对 100 个元素运行此代码,则会发生以下事情 -

对于排序数组 -

1, 2, 3, 4, 5, …… 50, 51………100
A, A, A, A, A A, B B

它将在管道中加载正确的分支和正确的顺序

A, A, A, A, A, A, A, A A, B B

对于未排序的数组 -

5, 51, 6, 90, 4, 49, 60…
A, B, A, B, A, A, A, B

分支预测在这里没有发挥重要作用。 很难预测 A 和 B 之间的正确操作。

关注这个oreilly 链接的视频通知JVM 使用Brach 预测

这是一段 C++ 代码,显示了一些非常奇特的行为。 出于某种奇怪的原因,对数据进行排序奇迹般地使代码快了近 6 倍:

#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)
    {
        for (unsigned c = 0; c < arraySize; ++c)
        {   // Primary loop
            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;
}
  • 没有std::sort(data, data + arraySize); ,代码运行时间为 11.54 秒。
  • 使用排序后的数据,代码运行时间为 1.93 秒。

最初,我认为这可能只是一种语言或编译器异常,所以我尝试了 Java:

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)
        {
            for (int c = 0; c < arraySize; ++c)
            {   // Primary loop
                if (data[c] >= 128)
                    sum += data[c];
            }
        }

        System.out.println((System.nanoTime() - start) / 1000000000.0);
        System.out.println("sum = " + sum);
    }
}

具有类似但不那么极端的结果。


我的第一个想法是排序将数据带入缓存,但后来我认为这是多么愚蠢,因为数组刚刚生成。

  • 到底是怎么回事?
  • 为什么处理排序数组比处理未排序数组更快?

代码总结了一些独立的术语,所以顺序应该无关紧要。


相关/后续问答关于不同/更高版本的编译器和选项的相同效果:

也许您不应该对数据进行排序,因为输出值范围是有限的。 计算每个值发生的次数要快得多。

例如,您在 0..3 之间有 20 个数据,那么您可以保留 3 个计数器。 最后你可能有:{ 0: 10x , 1: 8x, 2: 2x }

将此数组转换回线性数组很容易,只需打印 10x 0、8x 1、2x 2。

当值不是 0..2 但仍然有限时,您仍然可以考虑这种方法。 排序总是很慢! 其他优点:这是少量代码,易于阅读和测试,错误较少​​。

在运行时进行优化。

动态分支预测使用在运行时收集的有关已采用或未采用分支的信息来预测分支的结果。 - 维基百科。

这就是所有这些答案的内容。

如果处理归结为search ,则查找时间

在随机序列中是O(n) ,并且

在排序数组中O(log(n))

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题
 
粤ICP备18138465号  © 2020-2022 STACKOOM.COM