如果我优化大小而不是速度，为什么GCC会生成15-20％的代码？

Question

我在2009年首先注意到GCC（至少在我的项目和我的机器上）如果我优化尺寸（-Os）而不是速度（-O2或-O3），那么它倾向于产生明显更快的代码，而且我一直想知道为什么。

我设法创建（相当愚蠢）代码，显示这种令人惊讶的行为，并且足够小，无法在此处发布。

const int LOOP_BOUND = 200000000;

__attribute__((noinline))
static int add(const int& x, const int& y) {
    return x + y;
}

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

如果我用-Os编译它，执行这个程序需要0.38秒，如果用-O2或-O3编译它需要0.44秒。这些时间一致且几乎没有噪声（gcc 4.7.2，x86_64 GNU / Linux，Intel Core i5-3320M）。

（更新：我已将所有汇编代码移至GitHub：由于fno-align-*标志具有相同的效果，因此它们使得帖子变得臃肿并显然对问题增加了很少的价值。）

这是使用-Os和-O2生成的程序集。

不幸的是，我对装配的理解是非常有限的，所以我不知道我接下来做了什么是正确的：我抓住-O2的装配并将其所有差异合并到-Os的装配中，除了.p2align线，结果here。这段代码仍然在0.38s运行，唯一的区别是.p2align的东西。

如果我猜对了，这些是用于堆栈对齐的填充。根据Why does GCC pad functions with NOPs?的说法，它是希望代码运行得更快，但显然这种优化在我的情况下适得其反。

在这种情况下，填充物是否是罪魁祸首？为什么以及如何？

它产生的噪声几乎使得时序微观优化变得不可能。

当我在C或C ++源代码上进行微优化（与堆栈对齐无关）时，如何确保这种偶然的幸运/不幸对齐不会干扰？

更新：

在Pascal Cuoq's answer之后，我对齐了一点点。通过将-O2 -fno-align-functions -fno-align-loops传递给gcc，所有.p2align都从程序集中消失，生成的可执行文件在0.38秒内运行。根据gcc documentation：

-Os启用所有-O2优化[但] -Os禁用以下优化标志：

  -falign-functions  -falign-jumps  -falign-loops <br/>
  -falign-labels  -freorder-blocks  -freorder-blocks-and-partition <br/>
  -fprefetch-loop-arrays <br/>

所以，它几乎就像是一个（错误的）对齐问题。

我仍然对-march=native建议的Marat Dukhan's answer持怀疑态度。我不相信它不只是干扰这个（错误的）对齐问题;它对我的机器完全没有影响。（尽管如此，我还是赞成了他的答案。）

更新2：

我们可以从图片中取出-Os。通过编译获得以下时间

QZXSOP 0.Horse
QZXSOP 0.Horse
-O2 -fno-omit-frame-pointer然后在-O2 -fno-align-functions -fno-align-loops 0.37s之后手动移动-S -O2的组件
add() 0.44s

在我看来，work()与通话网站的距离非常重要。我尝试过-O2，但add()和perf的输出对我来说没什么意义。但是，我只能得到一个一致的结果：

perf stat：

perf report

对于-O2：

 602,312,864 stalled-cycles-frontend   #    0.00% frontend cycles idle
       3,318 cache-misses
 0.432703993 seconds time elapsed
 [...]
 81.23%  a.out  a.out              [.] work(int, int)
 18.50%  a.out  a.out              [.] add(int const&, int const&) [clone .isra.0]
 [...]
       ¦   __attribute__((noinline))
       ¦   static int add(const int& x, const int& y) {
       ¦       return x + y;
100.00 ¦     lea    (%rdi,%rsi,1),%eax
       ¦   }
       ¦   ? retq
[...]
       ¦            int z = add(x, y);
  1.93 ¦    ? callq  add(int const&, int const&) [clone .isra.0]
       ¦            sum += z;
 79.79 ¦      add    %eax,%ebx

对于fno-align-*：

 604,072,552 stalled-cycles-frontend   #    0.00% frontend cycles idle
       9,508 cache-misses
 0.375681928 seconds time elapsed
 [...]
 82.58%  a.out  a.out              [.] work(int, int)
 16.83%  a.out  a.out              [.] add(int const&, int const&) [clone .isra.0]
 [...]
       ¦   __attribute__((noinline))
       ¦   static int add(const int& x, const int& y) {
       ¦       return x + y;
 51.59 ¦     lea    (%rdi,%rsi,1),%eax
       ¦   }
[...]
       ¦    __attribute__((noinline))
       ¦    static int work(int xval, int yval) {
       ¦        int sum(0);
       ¦        for (int i=0; i<LOOP_BOUND; ++i) {
       ¦            int x(xval+sum);
  8.20 ¦      lea    0x0(%r13,%rbx,1),%edi
       ¦            int y(yval+sum);
       ¦            int z = add(x, y);
 35.34 ¦    ? callq  add(int const&, int const&) [clone .isra.0]
       ¦            sum += z;
 39.48 ¦      add    %eax,%ebx
       ¦    }

在缓慢的情况下，看起来我们正在停止对-fno-omit-frame-pointer的调用。

我检查了404,625,639 stalled-cycles-frontend # 0.00% frontend cycles idle 10,514 cache-misses 0.375445137 seconds time elapsed [...] 75.35% a.out a.out [.] add(int const&, int const&) [clone .isra.0] ¦ 24.46% a.out a.out [.] work(int, int) [...] ¦ __attribute__((noinline)) ¦ static int add(const int& x, const int& y) { 18.67 ¦ push %rbp ¦ return x + y; 18.49 ¦ lea (%rdi,%rsi,1),%eax ¦ const int LOOP_BOUND = 200000000; ¦ ¦ __attribute__((noinline)) ¦ static int add(const int& x, const int& y) { ¦ mov %rsp,%rbp ¦ return x + y; ¦ } 12.71 ¦ pop %rbp ¦ ? retq [...] ¦ int z = add(x, y); ¦ ? callq add(int const&, int const&) [clone .isra.0] ¦ sum += z; 29.83 ¦ add %eax,%ebx可以在我的机器上吐出的所有东西;不仅仅是上面给出的统计数据。

对于相同的可执行文件，add()显示与执行时间的线性相关;我没有注意到任何其他与此相关的内容。（比较perf -e的不同可执行文件对我来说没有意义。）

我将缓存未命中列为第一条评论。我检查了stalled-cycles-frontend可以在我的机器上测量的所有缓存未命中，而不仅仅是上面给出的。高速缓存未命中非常非常嘈杂，并且与执行时间几乎没有相关性。

Answer 1

另一答案