你的解释很正确。这似乎是一个在技术知识之外考验你自信的问题。

顺便说一下，如果你回答了

这两段代码同样快，因为它们都需要无限长的时间来完成

面试官会说

但是虽然(1)每秒可以做更多的迭代;你能解释一下原因吗?(这是无稽之谈;再次考验你的信心)

所以，通过像你那样回答，你节省了一些时间，否则你会浪费在讨论这个糟糕的问题上。

---

下面是编译器在我的系统(MS Visual Studio 2012)上生成的示例代码，优化关闭:

yyy:
    xor eax, eax
    cmp eax, 1     (or 2, depending on your code)
    je xxx
    jmp yyy
xxx:
    ...

打开优化后:

xxx:
    jmp xxx

因此生成的代码是完全相同的，至少在优化编译器中是如此。

这两个循环都是无限的，但我们可以看到哪个循环每次迭代需要更多的指令/资源。

使用gcc，我编译了以下两个程序，以不同的优化级别进行汇编:

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

即使没有优化(-O0)，两个程序生成的程序集也是相同的。因此，两个循环之间没有速度差异。

作为参考，下面是生成的程序集(使用gcc main.c -S -masm=intel并带有优化标志):

o0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

o1群:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

-O2和-O3(相同输出):

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

事实上，为循环生成的程序集对于每个级别的优化都是相同的:

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

重要的部分是:

.L2:
    jmp .L2

我不太懂汇编，但这显然是一个无条件循环。jmp指令无条件地将程序重置回. l2标签，甚至不将值与true进行比较，当然，它会立即再次这样做，直到程序以某种方式结束。这直接对应于C/ c++代码:

L2:
    goto L2;

编辑:

有趣的是，即使没有优化，下面的循环都在汇编中产生完全相同的输出(无条件jmp):

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

甚至令我惊讶的是:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

对于用户定义函数，事情变得更加有趣:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

At -O0, these two examples actually call x and perform a comparison for each iteration.

First example (returning 1):

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Second example (returning sqrt(7)):

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

However, at -O1 and above, they both produce the same assembly as the previous examples (an unconditional jmp back to the preceding label).

TL;DR

Under GCC, the different loops are compiled to identical assembly. The compiler evaluates the constant values and doesn't bother performing any actual comparison.

The moral of the story is:

• There exists a layer of translation between C source code and CPU instructions, and this layer has important implications for performance.
• Therefore, performance cannot be evaluated by only looking at source code.
• The compiler should be smart enough to optimize such trivial cases. Programmers should not waste their time thinking about them in the vast majority of cases.

You should have asked him how did he reached to that conclusion. Under any decent compiler out there, the two compile to the same asm instructions. So, he should have told you the compiler as well to start off. And even so, you would have to know the compiler and platform very well to even make a theoretical educated guess. And in the end, it doesn't really matter in practice, since there are other external factors like memory fragmentation or system load that will influence the loop more than this detail.

这里有一个问题:如果您实际编写一个程序并测量它的速度，两个循环的速度可能是不同的!以下是一些合理的比较:

unsigned long i = 0;
while (1) { if (++i == 1000000000) break; }

unsigned long i = 0;
while (2) { if (++i == 1000000000) break; }

添加了一些打印时间的代码后，一些随机的效果(比如循环在一条或两条缓存线中的位置)可能会产生影响。一个循环可能完全位于一条缓存线内，或者位于一条缓存线的开头，或者它可能横跨两条缓存线。因此，面试官说最快的可能真的是最快的——纯属巧合。

最坏的情况:优化编译器不知道循环做了什么，但知道执行第二个循环时产生的值与第一个循环产生的值相同。并为第一个循环生成完整代码，但不为第二个循环生成完整代码。

现有的答案显示了由特定编译器为特定目标使用特定选项集生成的代码，并不能完全回答这个问题——除非在特定的上下文中提出了这个问题(例如，“对于带有默认选项的x86_64，使用gcc 4.7.2哪个更快?”)。

就语言定义而言，在抽象机器中while(1)计算整数常数1,while(2)计算整数常数2;在这两种情况下，比较结果是否等于零。语言标准完全没有说明这两种构造的相对性能。

我可以想象，一个极其幼稚的编译器可能会为这两种表单生成不同的机器代码，至少在编译时没有请求优化。

另一方面，C编译器绝对必须在编译时计算一些常量表达式，当它们出现在需要常量表达式的上下文中时。例如，这个:

int n = 4;
switch (n) {
    case 2+2: break;
    case 4:   break;
}

需要诊断;延迟编译器没有将2+2的计算延迟到执行时的选项。由于编译器必须具备在编译时计算常量表达式的能力，因此即使不需要也没有充分的理由不利用这种能力。

C标准(N1570 6.8.5p4)说

一个迭代语句导致一个称为循环体的语句 重复执行，直到控制表达式比较为 0.

所以相关的常数表达式是1 == 0和2 == 0，它们的值都是int值0。(这些比较隐含在while循环的语义中;它们并不作为实际的C表达式存在。)

非常简单的编译器可能会为这两种构造生成不同的代码。例如，对于第一个，它可以生成一个无条件的无限循环(将1视为特殊情况)，对于第二个，它可以生成一个显式的运行时比较，等价于2 != 0。但我从来没有遇到过这样的C编译器，我严重怀疑这样的编译器是否存在。

大多数编译器(我倾向于说所有生产质量的编译器)都有请求额外优化的选项。在这种选择下，任何编译器都不太可能为这两种表单生成不同的代码。

如果编译器为这两种构造生成不同的代码，首先检查不同的代码序列是否具有不同的性能。如果有，请尝试使用优化选项(如果可用)再次编译。如果它们仍然不同，则向编译器供应商提交错误报告。这(不一定)是一个不符合C标准的错误，但几乎可以肯定这是一个应该纠正的问题。

底线:while(1)和while(2)几乎肯定具有相同的性能。它们具有完全相同的语义，任何编译器都没有理由不生成相同的代码。

尽管编译器为while(1)生成比while(2)更快的代码是完全合法的，但在同一个程序中，编译器为while(1)生成比另一个while(1)更快的代码也是合法的。

(你问的问题中还暗含着另一个问题:你如何应对坚持提出一个错误的技术观点的面试官?这可能是一个适合Workplace网站的好问题)。

它们是相等的。

根据规范，任何不为0的都被认为是真的，所以即使没有任何优化，一个好的编译器也不会生成任何代码 For while(1) or while(2)。编译器将生成一个简单的检查!= 0。

对这个问题最有可能的解释是，面试官认为处理器会逐一检查数字的每一位，直到它达到一个非零值:

1 = 00000001
2 = 00000010

如果“is 0 ?”算法从数字的右侧开始，并且必须检查每一位直到它达到非零位，那么while(1){}循环每次迭代必须检查的比特数是while(2){}循环的两倍。

这需要一个关于计算机如何工作的非常错误的思维模型，但它确实有自己的内部逻辑。一种检查方法是询问while(-1){}或while(3){}是否同样快，或者while(32){}是否更慢。

当然，我不知道这位经理的真实意图，但我提出了一个完全不同的观点:当一个团队雇佣一个新成员时，了解他如何应对冲突情况是很有用的。

他们让你陷入冲突。如果这是真的，他们很聪明，这个问题也很好。对于某些行业，比如银行业，将你的问题发布到Stack Overflow可能会成为被拒绝的理由。

但我当然不知道，我只是提出一个选择。

是的，对于人类来说，while(1)比while(2)快得多!如果我在一个不熟悉的代码库中看到while(1)，我立即知道作者的意图，我的眼球可以继续看下一行。

If I see while(2), I'll probably halt in my tracks and try to figure out why the author didn't write while(1). Did the author's finger slip on the keyboard? Do the maintainers of this codebase use while(n) as an obscure commenting mechanism to make loops look different? Is it a crude workaround for a spurious warning in some broken static analysis tool? Or is this a clue that I'm reading generated code? Is it a bug resulting from an ill-advised find-and-replace-all, or a bad merge, or a cosmic ray? Maybe this line of code is supposed to do something dramatically different. Maybe it was supposed to read while(w) or while(x2). I'd better find the author in the file's history and send them a "WTF" email... and now I've broken my mental context. The while(2) might consume several minutes of my time, when while(1) would have taken a fraction of a second!

我有点夸张，但也只是一点点。代码的可读性非常重要。这一点在面试中很值得一提!

我能想到为什么while(2)会更慢的唯一原因是:

代码将循环优化为 2 . CMP eax 当减法发生时，你实际上是在减法 A. 00000000 - 00000010 CMP eax, 2 而不是 B. 00000000 - 00000001 CMP eax, 1

CMP只设置标志，不设置结果。所以对于最低有效位，我们知道b是否需要借位，而对于a，你必须做两次减法才能得到借位。

我认为线索可以从“高级经理的询问”中找到。这个人显然在成为经理后就停止了编程，然后他/她花了几年时间才成为高级经理。从未失去对编程的兴趣，但从那以后再也没有写过一行字。所以他提到的并不是“任何一个像样的编译器”，而是“这个人在二三十年前合作过的编译器”。

At that time, programmers spent a considerable percentage of their time trying out various methods for making their code faster and more efficient as CPU time of 'the central minicomputer' was so valueable. As did people writing compilers. I'm guessing that the one-and-only compiler his company made available at that time optimized on the basis of 'frequently encountered statements that can be optimized' and took a bit of a shortcut when encountering a while(1) and evaluated everything else, including a while(2). Having had such an experience could explain his position and his confidence in it.

让你被录用的最好方法可能是，在你顺利地引导他进入下一个面试主题之前，让高级经理忘乎所以地给你讲2-3分钟“编程的美好时光”。(好的时机在这里很重要——太快你会打断故事——太慢你会被贴上焦点不集中的标签)。一定要在面试结束时告诉他，你对这个话题非常感兴趣。

关于这个问题的另一个答案是，看看你是否有勇气告诉你的经理他/她错了!以及你能多温柔地交流。

我的第一直觉是生成汇编输出，向管理器显示任何像样的编译器都应该照顾它，如果它不这样做，你将提交它的下一个补丁:)

这取决于编译器。

如果它优化了代码，或者对于一个特定的指令集，如果它用相同数量的指令计算1和2为真，那么执行速度将是相同的。

在实际情况下，它总是同样快，但可以想象在特定的编译器和特定的系统中，这将得到不同的计算。

我的意思是:这不是一个与语言(C)相关的问题。

看到这么多人深入研究这个问题，正好说明了为什么这可以很好地作为一个测试，看看您想要多快地进行微优化。

我的答案是;这并不重要，我更关注我们正在解决的业务问题。毕竟，这就是我的工作。

此外，我会选择while(1){}，因为它更常见，其他队友不需要花时间去弄清楚为什么有人会选择比1更高的数字。

现在去写一些代码。: -)

为了这个问题，我应该补充一点，我记得C委员会的Doug Gwyn写过，一些早期的C编译器如果没有优化器通道，会在汇编中生成一个while(1)的测试(相比之下，For(;;)没有它)。

我会给出这个历史笔记来回答面试官，然后说，即使我对任何编译器这样做感到非常惊讶，编译器也可以这样做:

没有优化器，通过编译器生成while(1)和while(2)测试 通过优化器传递，编译器被指示优化(无条件跳转)，而(1)，因为它们被认为是惯用的。这将使while(2)只剩下一个测试，从而导致两者之间的性能差异。

当然，我要向面试官补充的是，不考虑while(1)和while(2)相同的结构是低质量优化的标志，因为它们是等效的结构。

等一下。面试官长得像这个人吗?

面试官自己没能通过面试已经够糟糕的了， 如果这家公司的其他程序员已经“通过”了这个测试呢?

不。求值语句1 == 0和2 == 0应该同样快。我们可以想象，在糟糕的编译器实现中，一个可能比另一个快。但是，没有充分的理由说明其中一个应该比另一个快。

即使在某些模糊的情况下，这种说法是正确的，也不应该基于模糊(在这种情况下，令人毛骨悚然)琐事的知识来评估程序员。不要担心这次面试，最好的办法就是走开。

免责声明:这不是原创呆伯特漫画。这只是一个混搭。

根据人们花费在测试、证明和回答这个非常直接的问题上的时间和精力来判断，我认为这两者都因为提出这个问题而变得非常缓慢。

所以花更多的时间在这上面…

虽然(2)很荒谬，因为，

While(1)和While (true)在历史上被用于创建一个无限循环，该循环预计在循环中的某个阶段根据一定会发生的条件调用break。

1只是为了总是求值为真，因此，说while(2)和说while(1 + 1 == 2)一样愚蠢，后者也会求值为真。

如果你想完全傻一点，就用:-

while (1 + 5 - 2 - (1 * 3) == 0.5 - 4 + ((9 * 2) / 4.0)) {
    if (succeed())
        break;
}

我认为面试官犯了一个错别字，这并不影响代码的运行，但如果他故意使用2只是为了表现得奇怪，那么在他把奇怪的语句贯穿你的代码，使其难以阅读和使用之前解雇他。

我曾经用C语言和汇编代码编写程序，那时候这类废话可能会有很大不同。当它确实起作用时，我们在汇编中写了出来。

如果我被问到这个问题，我会重复唐纳德·克努特1974年关于过早优化的名言，如果面试官没有笑，我就会走开，然后继续前进。

在我看来，这是一个被伪装成技术问题的行为面试问题。有些公司会这样做——他们会问一个任何有能力的程序员都应该很容易回答的技术问题，但是当面试者给出正确答案时，面试官会告诉他们他们错了。

公司想看看你在这种情况下会作何反应。你是否会因为自我怀疑或害怕让面试官不高兴而安静地坐在那里，不强调自己的答案是正确的?或者你愿意挑战一个你知道是错误的权威人士吗?他们想看看你是否愿意坚持自己的信念，以及你是否能以一种机智和尊重的方式做到这一点。

也许面试官是故意问这个愚蠢的问题，想让你回答3点:

基本的推理。这两个循环都是无限的，很难谈论性能。 关于优化级别的知识。他想听听你的意见，如果你让编译器为你做任何优化，它会优化条件，特别是如果块不是空的。 了解微处理器架构。大多数架构都有一个特殊的CPU指令用于与0进行比较(但不一定更快)。

如果你担心优化，你应该使用

for (;;)

因为它没有检验。(愤世嫉俗者模式)

因为回答这个问题的人希望得到最快的循环，所以我的回答是，两者都是同样地编译成相同的汇编代码，正如在其他答案中所述。不过，你可以用“循环展开”向面试官建议;一个do {} while循环而不是while循环。

谨慎:您需要确保循环至少总是运行一次。

循环内部应该有一个中断条件。

同样，对于这种循环，我个人更喜欢使用do {} while(42)，因为除了0之外，任何整数都可以完成这项工作。

显而易见的答案是:正如所发布的，两个片段将运行一个同样繁忙的无限循环，这使得程序无限慢。

虽然从技术上讲，将C关键字重新定义为宏将具有未定义的行为，但这是我能想到的使任何一个代码片段快速的唯一方法:你可以在两个片段之上添加这一行:

#define while(x) sleep(x);

它确实会使while(1)比while(2)快一倍(或慢一半)。