我绝不是这方面的专家，但我似乎记得，当涉及到分支预测时，现代处理器相当敏感。用于预测分支的算法(至少在我编写汇编程序代码时是这样)基于代码的几个属性，包括目标的距离和方向。

我想到的场景是小循环。当分支向后走并且距离不是太远时，分支预测就会针对这种情况进行优化，因为所有的小循环都是这样完成的。当您在生成的代码中交换add和work的位置时，或者当两者的位置发生轻微变化时，同样的规则可能会发挥作用。

也就是说，我不知道如何验证这一点，我只是想让你知道，这可能是你想要研究的东西。

我添加这篇文章是为了指出，对齐对程序(包括大型程序)整体性能的影响已经被研究过了。例如，本文(我相信这篇文章的一个版本也出现在CACM中)展示了仅改变链接顺序和OS环境大小就足以显著改变性能。他们将此归因于“热循环”的一致性。

这篇题为“在没有做任何明显错误的事情的情况下产生错误的数据!”的论文说，由于程序运行环境中几乎不可控的差异而导致的无意的实验偏差可能会导致许多基准测试结果毫无意义。

我认为你在同一观察中遇到了不同的角度。

对于性能关键型代码，对于那些在安装或运行时评估环境并在关键例程的不同优化版本中选择本地最佳版本的系统来说，这是一个很好的论据。

我认为你可以得到与你所做的相同的结果:

我抓取了-O2的程序集，并将其所有差异合并到-Os的程序集中，除了.p2align行:

-O2 -falign-functions=1 -falign- leaps =1 -falign-loops=1 -falign-labels=115年来，我一直在用这些选项编译所有东西，每次我费心测量时，它们都比普通的-O2快。

另外，对于完全不同的上下文(包括不同的编译器)，我注意到情况类似:应该“优化代码大小而不是速度”的选项针对代码大小和速度进行优化。

如果我猜对了，这些是堆栈对齐的填充。

不，这与堆栈无关，默认生成的nop和options -falign-*=1 prevent用于代码对齐。

根据为什么GCC垫功能与NOPs?这样做是希望代码运行得更快，但显然这种优化在我的情况下适得其反。 在这种情况下，填充物是罪魁祸首吗?为什么?怎么做?

It is very likely that the padding is the culprit. The reason padding is felt to be necessary and is useful in some cases is that code is typically fetched in lines of 16 bytes (see Agner Fog's optimization resources for the details, which vary by model of processor). Aligning a function, loop, or label on a 16-bytes boundary means that the chances are statistically increased that one fewer lines will be necessary to contain the function or loop. Obviously, it backfires because these NOPs reduce code density and therefore cache efficiency. In the case of loops and label, the NOPs may even need to be executed once (when execution arrives to the loop/label normally, as opposed to from a jump).

如果您的程序受CODE L1缓存的限制，那么针对大小进行优化就会突然开始发挥作用。

当我最后检查时，编译器还不够聪明，不能在所有情况下都解决这个问题。

在您的例子中，-O3可能生成的代码足够用于两条缓存线，但-Os适合用于一条缓存线。

我的同事帮我找到了一个合理的答案。他注意到了256字节边界的重要性。他没有在这里注册，并鼓励我自己发布答案(并获得所有的名声)。

---

简短的回答:

在这种情况下，填充物是罪魁祸首吗?为什么?怎么做?

这一切都归结为结盟。对齐可以对性能产生重大影响，这就是为什么我们首先使用-falign-*标志。

我已经向gcc开发人员提交了一份(虚假的?)错误报告。事实证明，默认行为是“我们默认将循环对齐到8字节，但如果我们不需要填充超过10个字节，则尝试将其对齐到16字节。”显然，在这种特殊情况下以及在我的机器上，这种默认设置不是最佳选择。带有-O3的Clang 3.4 (trunk)进行了适当的对齐，生成的代码没有显示这种奇怪的行为。

当然，如果对齐不当，情况会更糟。一个不必要的/糟糕的对齐只会毫无理由地消耗字节，并可能增加缓存丢失等。

它产生的噪音使时间进行了微优化 不可能的。 我如何确保这种偶然的幸运/不幸的对齐 当我做微优化(与堆栈无关 对齐)的C或c++源代码?

简单地告诉gcc做正确的对齐:

g++ -O2 -falign-functions=16 -falign-loops=16

---

长一点的回答:

如果出现以下情况，代码运行速度会变慢:

一个XX字节的边界在中间切割add() (XX依赖于机器)。 如果对add()的调用必须跳过XX字节边界，并且目标没有对齐。 如果add()没有对齐。 如果循环没有对齐。

前两个在Marat Dukhan好心发布的代码和结果中都很明显。在这种情况下，gcc-4.8.1 -Os(在0.994秒内执行):

00000000004004fd <_ZL3addRKiS0_.isra.0>:
  4004fd:       8d 04 37                lea    eax,[rdi+rsi*1]
  400500:       c3   

256字节的边界将add()切到正中间，并且add()和循环都没有对齐。惊喜，惊喜，这是最慢的情况!

在gcc-4.7.3 -Os(在0.822秒内执行)的情况下，256字节的边界只切割到冷部分(但循环和add()都不会被切割):

00000000004004fa <_ZL3addRKiS0_.isra.0>:
  4004fa:       8d 04 37                lea    eax,[rdi+rsi*1]
  4004fd:       c3                      ret

[...]

  40051a:       e8 db ff ff ff          call   4004fa <_ZL3addRKiS0_.isra.0>

没有任何东西是对齐的，对add()的调用必须跳过256字节的边界。这段代码是第二慢的。

在gcc-4.6.4 -Os(在0.709秒内执行)的情况下，虽然没有任何对齐，但对add()的调用不需要跳过256字节的边界，而目标正好在32字节之外:

  4004f2:       e8 db ff ff ff          call   4004d2 <_ZL3addRKiS0_.isra.0>
  4004f7:       01 c3                   add    ebx,eax
  4004f9:       ff cd                   dec    ebp
  4004fb:       75 ec                   jne    4004e9 <_ZL4workii+0x13>

这是三个中最快的。为什么256字节的边界在他的机器上是特殊的，我将把它留给他去弄清楚。我没有这样的处理器。

现在，在我的机器上，我没有这个256字节的边界效果。在我的机器上，只有函数和循环对齐生效。如果我传递g++ -O2 -falign-functions=16 -falign-loops=16，那么一切都恢复正常:我总是得到最快的情况，时间不再对-fno- ignore -frame-pointer标志敏感。我可以传递g++ -O2 -falign-functions=32 -falign-loops=32或16的任何倍数，代码也不敏感。

我在2009年第一次注意到gcc(至少在我的项目和我的 机器)倾向于生成明显更快的代码 优化的大小(-Os)而不是速度(-O2或-O3)，我已经 从那以后就一直在想为什么。

一个可能的解释是，我的热点对对齐很敏感，就像这个例子中的一样。通过打乱标志(传递-Os而不是-O2)，这些热点以一种幸运的方式意外对齐，代码变得更快。这与优化大小无关:这些完全是偶然的，热点对齐得更好。从现在开始，我将检查对齐对我的项目的影响。

哦，还有一件事。这样的热点是如何出现的，就像例子中显示的那样?像add()这样的小函数的内联怎么会失败呢?

考虑一下:

// add.cpp
int add(const int& x, const int& y) {
    return x + y;
}

在一个单独的文件中:

// main.cpp
int add(const int& x, const int& y);

const int LOOP_BOUND = 200000000;

__attribute__((noinline))
static int work(int xval, int yval) {
    int sum(0);
    for (int i=0; i<LOOP_BOUND; ++i) {
        int x(xval+sum);
        int y(yval+sum);
        int z = add(x, y);
        sum += z;
    }
    return sum;
}

int main(int , char* argv[]) {
    int result = work(*argv[1], *argv[2]);
    return result;
}

编译为:g++ -O2 add.cpp main.cpp。

gcc不会内联add()!

就这样，很容易无意中创建像op中那样的热点。当然，这在一定程度上是我的错:gcc是一个优秀的编译器。如果将上面的代码编译为:g++ -O2 -flto add.cpp main.cpp，也就是说，如果我进行链接时间优化，代码在0.19秒内运行!

(内联在OP中被人为禁用，因此，OP中的代码慢了2倍)。

我绝不是这方面的专家，但我似乎记得，当涉及到分支预测时，现代处理器相当敏感。用于预测分支的算法(至少在我编写汇编程序代码时是这样)基于代码的几个属性，包括目标的距离和方向。

我想到的场景是小循环。当分支向后走并且距离不是太远时，分支预测就会针对这种情况进行优化，因为所有的小循环都是这样完成的。当您在生成的代码中交换add和work的位置时，或者当两者的位置发生轻微变化时，同样的规则可能会发挥作用。

也就是说，我不知道如何验证这一点，我只是想让你知道，这可能是你想要研究的东西。