Question

如果在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是完全正确的模糊，我需要更多的解释来了解发生了什么。

更新：因为它出现在评论中：奇怪的表现行为w.r.t. -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

effect of branch prediction

带有cmov指令的代码对p绝对不敏感。如果cmov或p<0.26并且最多快4.38倍（0.81<p），则没有 p=1指令的代码将成为赢家。当然，分支预测器的更糟糕的情况是在p=0.5左右，其中代码比具有cmov指令的代码慢1.58倍。

Answer 1

注意：图表更新之前已回答问题;这里的一些汇编代码引用可能已经过时了。

（从我们上面的聊天中进行了改编和扩展，这足以激励我做更多的研究。）

首先（根据我们的上述聊天），您的第一个问题的答案似乎是“是”。在向量“优化”代码中，影响性能的优化（负面）是分支预测 a ，而在原始代码中，性能受（分支）<正面影响< EM>预测。（注意前者额外的' a '。）

重新提出你的第三个问题：即使在你的情况下，实际上没有进行矢量化，从步骤11（“条件执行”）here看来，与矢量化优化相关的步骤之一是“在目标循环中展平“条件”，就像循环中的这一点：

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

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

这解释了编译器使用条件移动指令（cmovl）的原因。目标是完全避免分支（而不是试图正确地预测）。相反，两条cmovl指令将在前一个cmpl的结果已知之前从管道发送，然后比较结果将被“转发”以在其回写之前启用/阻止移动（即，在它们实际生效之前）。

请注意，如果循环已经被矢量化，那么这可能是值得的，以便能够有效地并行完成循环的多次迭代。

但是，在您的情况下，优化尝试实际上是逆火，因为在展平循环中，两个条件移动通过循环每次都通过管道发送。这本身也可能不是那么糟糕，除了存在RAW数据危险导致第二次移动（cmovl %esi, %ecx）必须等到阵列/内存访问（movl (%rsp,%rsi,4), %esi）完成，即使结果最终会被忽略。因此花费在特定cmovl上的巨大时间。（我希望这是一个问题，你的处理器没有足够复杂的逻辑内置到其预测/转发实现中来处理危险。）

另一方面，在非优化的情况下，正如您所理解的那样，分支预测可以帮助避免必须等待相应的数组/内存访问的结果（ movl (%rsp,%rcx,4), %ecx指令）。在这种情况下，当处理器正确预测一个被采用的分支时（对于一个全0的数组，它将是每一次，但是[even]在随机数组中应该[仍然] 粗略超过 [编辑@Yakk的评论]一半的时间），它不必等待内存访问完成继续并在循环中排队接下来的几条指令。因此，在正确的预测中，你得到了提升，而在不正确的预测中，结果并不比“优化”情况更差，而且更好，因为有时能够避免2“浪费”cmovl管道中的说明。

[由于我根据您的评论错误地假设您的处理器，因此删除了以下内容。]
回到你的问题，我建议查看上面的链接，了解有关矢量化的标志的更多内容，但最后，我很确定忽略优化，因为你的Celeron不具备无论如何使用它（在这种情况下）。

[删除上面后添加]
重新提出你的第二个问题（“ ......我怎么能阻止gcc发出这条指令... ”），你可以试试-fno-if-conversion和-fno-if-conversion2标志（不确定）如果它们总是有效 - 它们不再适用于我的mac），虽然我认为你的问题一般都不是cmovl指令（即，我不会总是使用那些flags），只是在这个特定的上下文中使用它（鉴于@ Yakk关于你的排序算法的观点，分支预测会非常有用）。

为什么树矢量化使这种排序算法慢2倍？

1 个答案: