为什么 GCC 没有尽可能地优化这组分支和条件？

Question

以下三段代码实现的效果完全相同。然而，当在 GCC 4.5.2 上使用 -O3 编译时，大量迭代的时间差异很大。

1 - 正常分支，使用多个条件，最佳时间 1.0：

// a, b, c, d are set to random values 0-255 before each iteration.
if (a < 16 or b < 32 or c < 64 or d < 128) result += a+b+c+d;

2 - 分支，手动使用按位或检查条件，最佳时间 0.92：

if (a < 16 | b < 32 | c < 64 | d < 128) result += a+b+c+d;

3 - 最后，在没有分支的情况下得到相同的结果，最佳时间 0.85：

result += (a+b+c+d) * (a < 16 | b < 32 | c < 64 | d < 128);

当作为我制作的基准程序的内部循环运行时，上述时间是每种方法的最佳时间。 random() 在每次运行前都以相同的方式播种。

在我做这个基准测试之前，我认为 GCC 会优化掉这些差异。尤其是第二个例子让我摸不着头脑。谁能解释一下为什么 GCC 不把这样的代码变成等效的更快的代码？

编辑：修复了一些错误，并明确了随机数是无论如何创建和使用的，以免被优化掉。他们总是在原始基准中，我只是把我放在这里的代码搞砸了。

这是一个实际基准函数的示例：

boost::random::mt19937 rng;
boost::random::uniform_int_distribution<> ranchar(0, 255);

double quadruple_or(uint64_t runs) {
  uint64_t result = 0;
  rng.seed(0);

  boost::chrono::high_resolution_clock::time_point start = 
    boost::chrono::high_resolution_clock::now();
  for (; runs; runs--) {
    int a = ranchar(rng);
    int b = ranchar(rng);
    int c = ranchar(rng);
    int d = ranchar(rng);
    if (a < 16 or b < 32 or c < 64 or d < 128) result += a;
    if (d > 16 or c > 32 or b > 64 or a > 128) result += b;
    if (a < 96 or b < 53 or c < 199 or d < 177) result += c;
    if (d > 66 or c > 35 or b > 99 or a > 77) result += d;
  }

  // Force gcc to not optimize away result.
  std::cout << "Result check " << result << std::endl;
  boost::chrono::duration<double> sec = 
    boost::chrono::high_resolution_clock::now() - start;
  return sec.count();
}

The full benchmark can be found here.

Answer 1

自我最初的回答以来，OP 发生了一些变化。让我试着重温这里。

在情况 1 中，由于 or 短路，我希望编译器生成四个比较然后分支代码段。分支显然会非常昂贵，尤其是如果它们没有按照预期的路径运行。

在情况 2 中，编译器可以决定进行所有四个比较，将它们转换为 bool 0/1 结果，然后按位 or 所有四个部分一起，然后执行单个（附加）分支。这可能会用更多的比较来换取可能更少的分支。似乎减少分支数量确实可以提高性能。

在第 3 种情况下，情况与第 2 种情况几乎相同，只是在最后，可以通过明确告诉编译器“我知道结果将是 0 或 1，所以只需将左边的东西相乘，就可以消除另一个分支按那个值”。乘法显然比硬件上的相应分支更快。这与第二个示例形成对比，其中编译器不知道按位 or 的可能输出范围，因此它必须假设它可以是任何整数，并且必须进行比较和跳转。

历史原答案： 如果 random 有副作用（普通 PRNG 会），第一种情况在功能上与第二种和第三种不同，因此编译器可能会以不同方式优化它们是有道理的。具体来说，第一种情况只会调用random 所需的次数以通过检查，而在其他两种情况下，random 将始终调用四次。这将（假设 random 确实是有状态的）导致未来的随机数不同。

第二个和第三个之间的区别是因为编译器可能由于某种原因无法计算出按位 or 的结果将始终为 0 或 1。当您提示它执行乘法而不是分支时由于流水线，乘法可能会更快。

Answer 2

使用逻辑运算符，代码将分支并提前退出。位运算符总是能完成全部工作。

分支预测在第一种情况下会更差，尽管它会在更大的示例中优于按位情况。

它无法优化掉random()，因为该函数不是pure（幂等）。

Answer 3

您始终可以尝试优化分支并相乘。而不是：

if (test) result+= blah;

或

result+= blah*(test);

你可以这样做：

result+= blah&(-(test));

如果test 为假，则-false==0 和(blah&0)==0。如果test 为真，则-true==~0 和(blah&~0)==blah。您可能不得不将test 设置为!!test 以确保true==1。

Answer 4

在我的带有 gcc 4.5.3 的机器（Intel E5503）上，我发现版本 1 通常是最快的，尽管差异在测量噪声范围内（f3 是最慢的，虽然只比 f1 慢 2%） .

您如何衡量您的时间安排？您可能会发现，您看到的差异更多地是由于生成的代码的实际差异。