为什么 n++执行速度比 n=n+1 更快？

Question

在C语言中，为什么n++执行速度比n=n+1快？

(int n=...;  n++;)
(int n=...;  n=n+1;)

我们的老师在今天的课堂上问了这个问题。 （这不是家庭作业）

Answer 1

如果您正在使用“石器时代”编译器，情况就是如此……

对于“石器时代”：
++n 比 n++ 快于 n=n+1
机器通常有增量x以及向x添加const

• 在n++的情况下，你将只有2个内存访问（读n, inc n, write n )
• 如果是 n=n+1，您将有 3 次内存访问（读取 n、读取 const、添加 n 和 const、写入 n）

但是今天的编译器会自动将 n=n+1 转换为 ++n，而且它会做的事情比你想象的还要多！！

还有今天的out-of-顺序处理器 - 尽管存在“石器时代”编译器 - 在许多情况下运行时可能根本不会受到影响！

相关

Answer 2

在 x86 的 GCC 4.4.3 上，无论有没有优化，它们都会编译为完全相同的汇编代码，因此执行时间相同。正如您在汇编中看到的，GCC 只是将 n++ 转换为 n=n+1，然后将其优化为单指令添加（在 -O2 中）。

您的讲师关于 n++ 更快的建议仅适用于非常旧的非优化编译器，这些编译器不够智能，无法为 n = n + 1 选择就地更新指令>。这些编译器在 PC 世界中已经过时多年，但在奇怪的专有嵌入式平台上仍然可以找到。

C 代码：

int n;

void nplusplus() {
    n++;
}

void nplusone() {
    n = n + 1;
}

输出汇编（无优化）：

    .file   "test.c"
    .comm   n,4,4
    .text
.globl nplusplus
    .type   nplusplus, @function
nplusplus:
    pushl   %ebp
    movl    %esp, %ebp
    movl    n, %eax
    addl    $1, %eax
    movl    %eax, n
    popl    %ebp
    ret
    .size   nplusplus, .-nplusplus
.globl nplusone
    .type   nplusone, @function
nplusone:
    pushl   %ebp
    movl    %esp, %ebp
    movl    n, %eax
    addl    $1, %eax
    movl    %eax, n
    popl    %ebp
    ret
    .size   nplusone, .-nplusone
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

输出汇编（带 -O2 优化）：

    .file   "test.c"
    .text
    .p2align 4,,15
.globl nplusplus
    .type   nplusplus, @function
nplusplus:
    pushl   %ebp
    movl    %esp, %ebp
    addl    $1, n
    popl    %ebp
    ret
    .size   nplusplus, .-nplusplus
    .p2align 4,,15
.globl nplusone
    .type   nplusone, @function
nplusone:
    pushl   %ebp
    movl    %esp, %ebp
    addl    $1, n
    popl    %ebp
    ret
    .size   nplusone, .-nplusone
    .comm   n,4,4
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

Answer 3

编译器会将n + 1优化为空。

您的意思是 n = n + 1 吗？

如果是这样，它们将编译为相同的程序集。 （假设优化已开启并且它们是语句，而不是表达式）

Answer 4

谁说可以的？您的编译器实际上将其全部优化掉，使其成为一个没有实际意义的问题。

Answer 5

现代编译器应该能够将这两种形式识别为等效形式，并将它们转换为最适合您的目标平台的格式。此规则有一个例外：具有副作用的变量访问。例如，如果n是某个内存映射的硬件寄存器，则从它读取和写入它可能不仅仅只是传输数据值（例如，读取可能会清除中断）。您可以使用易失性关键字让编译器知道它需要小心优化对n的访问，在这种情况下，编译器可能会生成与不同的代码>n++（递增操作）和n = n + 1（读取、添加和存储操作）。然而，对于普通变量，编译器应该将两种形式优化为相同的东西。

Answer 6

事实并非如此。编译器将针对目标体系结构进行更改。像这样的微观优化通常会带来可疑的好处，但重要的是，这肯定不值得程序员花时间。

Answer 7

实际上，原因是后修复操作符的定义与前置修复操作符的定义不同。 ++n 将递增“n”并返回对“n”的引用，而 n++ 将递增“n”将返回一个 const 副本“n”。因此，短语n = n + 1会更有效。但我不得不同意上面的海报。好的编译器应该优化掉未使用的返回对象。

Answer 8

在 C 语言中，n++ 表达式的副作用根据定义等价于 n = n + 1 表达式的副作用。由于您的代码仅依赖于副作用，因此很明显正确的答案是这些表达式始终具有完全相同的性能。 （顺便说一句，无论编译器中的任何优化设置如何，因为该问题与任何优化完全无关。）

只有当编译器有意（并且恶意！）尝试引入这些表达式时，这些表达式的性能才有可能出现任何实际差异 。分歧。但在这种情况下，当然，它可以采用任何一种方式，即编译器作者想要倾斜它的方式。

Answer 9

我认为这更像是硬件问题而不是软件问题...如果我没记错的话，在较旧的CPU中，n=n+1需要两个内存位置，其中++n只是一个微控制器命令...但我怀疑这适用于现代建筑......

Answer 10

所有这些都取决于编译器/处理器/编译指令。因此，做出“一般情况下什么更快”的假设并不是一个好主意。