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

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

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

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

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

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

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网站的好问题)。

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.

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

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

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

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分钟“编程的美好时光”。(好的时机在这里很重要——太快你会打断故事——太慢你会被贴上焦点不集中的标签)。一定要在面试结束时告诉他，你对这个话题非常感兴趣。