c++ - 为什么树向量化会使这种排序算法慢2倍？

如果在gcc(4.7.2)中启用了-fprofile-arcs，则this question的排序算法将变得更快(!)两倍。这个问题经过高度简化的C代码(事实证明，我可以使用全零来初始化数组，但仍存在怪异的性能行为，但这使推理变得简单得多):

#include <time.h>
#include <stdio.h>

#define ELEMENTS 100000

int main() {
  int a[ELEMENTS] = { 0 };
  clock_t start = clock();
  for (int i = 0; i < ELEMENTS; ++i) {
    int lowerElementIndex = i;
    for (int j = i+1; j < ELEMENTS; ++j) {
      if (a[j] < a[lowerElementIndex]) {
        lowerElementIndex = j;
      }
    }
    int tmp = a[i];
    a[i] = a[lowerElementIndex];
    a[lowerElementIndex] = tmp;
  }
  clock_t end = clock();
  float timeExec = (float)(end - start) / CLOCKS_PER_SEC;
  printf("Time: %2.3f\n", timeExec);
  printf("ignore this line %d\n", a[ELEMENTS-1]);
}

长时间使用优化标志后，事实证明-ftree-vectorize也会产生这种怪异的行为，因此我们可以将-fprofile-arcs排除在问题之外。用perf分析后，我发现唯一相关的区别是:

快速案例gcc -std=c99 -O2 simp.c(运行3.1秒)

    cmpl    %esi, %ecx
    jge .L3
    movl    %ecx, %esi
    movslq  %edx, %rdi
.L3:

慢速gcc -std=c99 -O2 -ftree-vectorize simp.c(运行6.1s)

    cmpl    %ecx, %esi
    cmovl   %edx, %edi
    cmovl   %esi, %ecx

至于第一个片段:鉴于数组仅包含零，我们总是跳到.L3。它可以极大地受益于分支预测。

我猜cmovl指令不能从分支预测中受益。

问题:

我以上所有的猜测正确吗？这会使算法变慢吗？

如果可以，如何防止gcc发出此指令(当然，除了琐碎的-fno-tree-vectorization解决方法以外)，但仍要进行尽可能多的优化？

这是什么-ftree-vectorization？ The documentation相当
含糊不清，我需要更多说明才能了解发生了什么。

更新:由于出现在注释中:奇怪的性能行为-ftree-vectorize标志保留随机数据。 As Yakk points out，对于选择排序，实际上很难创建一个数据集，该数据集会导致很多分支预测错误。

由于它也出现了:我有一个Core i5 CPU。

Based on Yakk's comment，我创建了一个测试。下面的代码(online without boost)当然不再是排序算法；我只取出内循环。它的唯一目标是检查分支预测的效果:我们以if概率跳过for循环中的p分支。

#include <algorithm>
#include <cstdio>
#include <random>
#include <boost/chrono.hpp>
using namespace std;
using namespace boost::chrono;
constexpr int ELEMENTS=1e+8;
constexpr double p = 0.50;

int main() {
  printf("p = %.2f\n", p);
  int* a = new int[ELEMENTS];
  mt19937 mt(1759);
  bernoulli_distribution rnd(p);
  for (int i = 0 ; i < ELEMENTS; ++i){
    a[i] = rnd(mt)? i : -i;
  }
  auto start = high_resolution_clock::now();
  int lowerElementIndex = 0;
  for (int i=0; i<ELEMENTS; ++i) {
    if (a[i] < a[lowerElementIndex]) {
      lowerElementIndex = i;
    }
  }
  auto finish = high_resolution_clock::now();
  printf("%ld  ms\n", duration_cast<milliseconds>(finish-start).count());
  printf("Ignore this line   %d\n", a[lowerElementIndex]);
  delete[] a;
}

感兴趣的循环:

这将被称为 cmov
g++ -std=c++11 -O2 -lboost_chrono -lboost_system -lrt branch3.cpp

    xorl    %eax, %eax
.L30:
    movl    (%rbx,%rbp,4), %edx
    cmpl    %edx, (%rbx,%rax,4)
    movslq  %eax, %rdx
    cmovl   %rdx, %rbp
    addq    $1, %rax
    cmpq    $100000000, %rax
    jne .L30

这将被称为 no cmov ，Turix in his answer.指出了-fno-if-conversion标志
g++ -std=c++11 -O2 -fno-if-conversion -lboost_chrono -lboost_system -lrt branch3.cpp

    xorl    %eax, %eax
.L29:
    movl    (%rbx,%rbp,4), %edx
    cmpl    %edx, (%rbx,%rax,4)
    jge .L28
    movslq  %eax, %rbp
.L28:
    addq    $1, %rax
    cmpq    $100000000, %rax
    jne .L29

并排的差异

cmpl    %edx, (%rbx,%rax,4) |     cmpl  %edx, (%rbx,%rax,4)
movslq  %eax, %rdx          |     jge   .L28
cmovl   %rdx, %rbp          |     movslq    %eax, %rbp
                            | .L28:

执行时间与伯努利参数p的关系

带有cmov指令的代码对p绝对不敏感。如果不使用cmov或p<0.26，则没有0.81<p指令的代码将是赢家，并且最多快4.38倍(p=1)。当然，对于分支预测器而言，最糟糕的情况是在p=0.5附近，该代码比使用cmov指令的代码慢1.58倍。

最佳答案

注意:在将图形更新添加到问题之前已回答；某些汇编代码引用可能已过时。

(从上面的聊天中进行了调整和扩展，这种刺激足以使我进行更多的研究。)

首先(根据我们上面的聊天)，第一个问题的答案似乎是"is"。在 vector “优化”代码中，影响性能的优化(负面影响)是分支预测，而在原始代码中，性能(正面)受分支预测影响。 (请注意前一个额外的' a '。)

关于您的第三个问题:即使您的情况实际上没有进行向量化，从步骤11(“有条件的执行”)here来看，与向量化优化相关的步骤之一似乎是在目标循环内“拉平”条件，像这样循环:

if (a[j] < a[lowerElementIndex]
    lowerElementIndex = j;

显然，即使没有向量化，也会发生这种情况。

这解释了为什么编译器使用条件移动指令(cmovl)。那里的目标是完全避免分支(而不是尝试正确地预测分支)。取而代之的是，这两个cmovl指令将在已知前一个cmpl的结果之前沿管道发送，然后将“转发”比较结果以启用/防止在写回之前执行这些 Action (即，在它们实际生效之前) )。

请注意，如果已对循环进行矢量化处理，那么可以有效地并行完成循环中的多次迭代，这可能是值得的。

但是，在您的情况下，优化尝试实际上会适得其反，因为在扁平化循环中，两次有条件移动都是通过循环每次通过管道发送的。这本身可能还不是很糟糕，只是存在RAW数据危险，导致第二步(cmovl %esi, %ecx)必须等待直到阵列/内存访问(movl (%rsp,%rsi,4), %esi)完成，即使结果将是最终被忽略了。因此，在该特定cmovl上花费了大量时间。 (我希望这是您的处理器在其谓词/转发实现中没有足够复杂的逻辑来处理危险的问题。)

另一方面，如您正确地指出的那样，在非优化的情况下，分支预测可以帮助避免不得不等待那里相应的数组/内存访问的结果(movl (%rsp,%rcx,4), %ecx指令)。在那种情况下，当处理器正确预测一个采用分支时(全0数组将是每一次，但随机数组中的[偶数]应[仍然]大约大于[按@Yakk的评论编辑]的一半)时间)，它不必等待内存访问完成就可以在循环中将接下来的几条指令排队。因此，在正确的预测中，您会得到提升；而在错误的预测中，结果不会比“优化”情况下更糟，而且，由于有时能够避免在管道中使用2条“浪费”的cmovl指令，结果会更好。

[由于我根据您的评论对处理器的错误假设，删除了以下内容。]
回到您的问题，我建议您查看上面的链接，以获得更多与矢量化有关的标志，但是最后，我很确定可以忽略这种优化，因为您的赛扬无法使用它(在这种情况下)。

[删除以上内容后添加]
关于第二个问题(“...我如何防止gcc发出此指令...”)，您可以尝试-fno-if-conversion和-fno-if-conversion2标志(不确定它们是否始终有效-它们在我的mac上不再起作用)，尽管我不认为您的问题通常是与cmovl指令有关的(即，我不会总是使用这些标志)，但仅在特定的上下文中使用它(考虑到@Yakk的观点，分支预测将非常有帮助)您的排序算法)。