Interesting question. Yes, as the answers state, there is almost no reason why the two programs should iterate at different speeds, especially when the compiler optimises the loop into an unconditional jump.<p>However, back in the day, with some CPU architectures, and with some fairly primitive compilers, it is conceivable for while(1) and while(something) to iterate at different rates. That is if the compiler outputs literal unoptimised code, and the something is a number large enough to require a larger instruction to initialise in a register than the number 1.<p>For example, the 68000 CPU instruction code has a quick immediate addressing mode, which can form the moveq instruction that will embed a constant between -128 and 127 into the instruction. It also has a slower immediate addressing mode that allows full 32-bit numbers to be sourced from an extra 32 bits tacked onto the end of the instruction. Therefore, while(1) {} could conceivably be compiled to:<p><pre><code> label:
moveq #1,D1
cmpi #0,D1
bne label (branch if not equal)
</code></pre>
whereas while(200) {} would be compiled to:<p><pre><code> label:
movei #200,D1
cmpi #0,D1
bne label
</code></pre>
and this loop would run slower than the first.
Is it just me, or is most everyone missing the point that neither of these terminate, and therefore both take "infinite time."<p>It seems we're all getting hung up on whether evaluating the truthiness of 1 or 2 is faster, but that's really immaterial.
While not <i>directly</i> pertaining to the question, there are precedents for languages to special-case some inputs to loops for various reasons. Specifically, I'm thinking of Java here. Note the following code:<p><pre><code> int x;
while (true) {
x = 8;
break;
}
System.out.println(x);
</code></pre>
This code compiles and runs. Java is smart enough to statically prove that the loop condition is true, and so it guarantees that `x` will always be initialized.<p>Instead of `true`, you can also use things like `1==1` in the condition to the same effect. However, if you attempt the following:<p><pre><code> int x;
boolean y = true;
while (y) {
x = 8;
break;
}
System.out.println(x);
</code></pre>
...the compiler will spit an error at you:<p><pre><code> While.java:9: error: variable x might not have been initialized
System.out.println(x);
^
</code></pre>
From a language design perspective, it's interesting to note this sort of demand and support for infinite loops in the language specification. One alternative to special-casing `while (true)` as shown above is to have an entirely separate construct for "I want this loop to be infinite", such as the `loop` keyword in Rust, or the bare `for` in Go. Alternatively, see how style guides for C-like languages tend to prefer `for (;;)` over `while (1)` to denote deliberately-infinite loops, to make the intent as obvious as possible.
This question was asked to me in a major MNC by a senior manager, after 4 technical round.
He started off by asking how do I manage conflict in team and went on to say "for example, if you write while (2) { // some code } and someone in code review suggests that replace this with while (1) or vice-versa, then how do you handle the conflict and how do convince him". I said both are same speed. he interuppted and said "check your basics, while (1) is faster " and moved on to next set of questions.
He was not testing my confidence. He actually bilived that while 1 is faster.
So this is an interview question, apparently by a senior manager. The obvious reply should be: What do you mean by faster? Do u mean writing this code is faster? Reading this code is faster? Compilation is faster OR may be you mean execution is faster? In case you meant execution then could you please mention the kind of computer on which the execution will happen? By the way it seems that both the code will run forever and ever, you can't figure out who won a race until the race ends and here it seems the race is going on forever.
A similar question, which is more apt for worthy discussion would be, is bool casting O(1), that is, constant time ?<p>And that might differ between JITs and compiled languages and different numerical types.<p>For any machine precision numerical types, if the code is compiled, it'll just become<p>TEST EAX, EAX
...set eax to 0 or 1 based on jmp...<p>So in most compiled languages, a bool cast on machine precision numerics, will be constant time.
i hope the answer the interviewer was looking for was:
"i'm unsure.. i usually check the byte code when i am optimising my work";
stead a flat "No" (the original poster claimed the interviewer said the run times were unequal)