-3

I know that if the while loop has this body:

while(a<b){
  do_some_calculations
 }

it will do calculations and then check the while loop again.But if I have an empty while loop:

while(a<b) { }

How often it will check the condition?I know that while loop compiles to cmp and jmp instructions (which takes from one to two cycles). So it will check while loop every 1-2 cycles?Or not and there are some things I don't know? Detail explanations will be very helpful.

P.S. The question is about the low level details. Please read it more attentively.And I want to know common principles and not "it is compiler dependent and so on".

P.P.S Let's suppose we have some valid condition and compiler generated code for it.HOW OFTEN it will check it?That's the question.

MainstreamDeveloper00
  • 8,436
  • 15
  • 56
  • 102

7 Answers7

4

Because the standards allow for many solutions in the generated assembly, your question really boils down to "what do compilers do?" and as such is only answerable by example.

I have performed the following test with GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00):

main.cpp:

int main() {
    while (true) { }
}

I compiled it with the following command line:

g++ -S main.cpp

And a stripped down version of the output, main.S, looks like this:

LBB1_1:
    jmp  LBB1_1

So with no optimization, the compiler recognizes that there is no condition to check, so it just generates a tight loop.

I suspect that other compilers will do the same thing, at least if any optimization is enabled. The only way to be sure is to check :)

Magnus Hoff
  • 21,529
  • 9
  • 63
  • 82
  • Thanks. But see my edits.Yes - I give not a correct way of condition. But lets suppose we have a valid condition but an empty body.How often it will check it? – MainstreamDeveloper00 Mar 21 '13 at 11:51
  • 2
    @HarryCater What do you mean by "how often"? Is "in a tight loop" a good enough answer? "As often as possible"? Or do you want it in Hz? I.e. "how many times per second is the test performed?" What is the specific programming problem you are trying to solve, as per the FAQ? – Magnus Hoff Mar 21 '13 at 11:53
  • @HarryCater, if the loop body is empty, then it can't affect the condition's result. Therefore, if it was true once, it will always be true. That is, unless the condition itself has side effects (e.g. `i++ – ugoren Mar 21 '13 at 12:06
  • @MagnusHoff - like you I began answering the unconditional loop question, and I found the same - a C program with a `while (1)` compiled exactly the same assembly as the program with a `goto`. – teppic Mar 21 '13 at 12:06
4

You don't seem to ask the right question. If the question involves the language that produces the assembler code, your answer will be, that it depends on the compiler, the optimization level and certain other things, but most importantly, it will depend on the condition. Each loop will do one test. If that test includes going to a database and check something there, your loop will be executed far less often than if you check the local time against some expiry time (as an example). Without further knowledge about the condition, there is no general answer possible. Depending on the condition, of course, the compiler will sometimes be able to optimize the test, but only if the visible behaviour of the code will not depend on it. So conceptually, the condition is still checked on each iteration. Until, of course, the condition yields false and the loop ends.

Daniel Frey
  • 55,810
  • 13
  • 122
  • 180
2

Your code will create a tight loop but if it will be empty it will be just an infinite loop like for (;;) - the loop with no terminating condition and it will eat all the processor resources or 100% / number_of_cores if it is multicore.In old operation systems such a code is able to make the entire system "freeze", but now all OS's schedulers are preemptive so it will executes only a time quantum (from 1 to 200 ms depending on OS) and inside this quantum it will execute without interruptions every 2-5 cycles if the body is empty and if compiler doesn't remove your condition because of optimisation. So I think and as I see many people think so your question is vague and incorrect.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
Oleksandr Karaberov
  • 12,573
  • 10
  • 43
  • 70
1

It will generate code that behaves as if the condition was checked every iteration.

If the compiler can prove that checking the condition on every iteration is unnecessary, then it may remove the check. But that is up to the individual compiler, and depends on the precise code you feed it.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • "was checked every iteration." That's the thing. i want to know how often it will be. – MainstreamDeveloper00 Mar 21 '13 at 11:54
  • 1
    @HarryCater: and the answer is exactly what I said: the program is required to behave *as if* it was checked in every iteration. If the compiler can prove that this is unnecessary, then it may remove some or all of the checks. So the answer is "It depends. If you need to know, look at the code generated by your compiler". – jalf Mar 21 '13 at 12:39
  • There is a discussion here http://stackoverflow.com/questions/3592557/optimizing-away-a-while1-in-c0x that indicates that the compiler may be allowed to remove the loop entirely because it can see the loop does nothing and doing nothing over and over is still nothing so it can replace the loop by doing nothing. It's not required to prove that the loop actually terminates. It's not really an answer but still interesting – jcoder Mar 21 '13 at 14:31
1

In a while loop, the condition will be checked before entering the loop, so it will be checked one more time than the number of times you go through the loop.

At least in the abstract machine. The compiler is allowed to optimize. Thus, in your example, if the compiler can know the values of a and b (because e.g. they were assigned with constants immediately before), then it may generate no code to do the check. If the loop visibly doesn't contain anything which can change the condition, it may generate no checking after the first check, since the results can't change. The only real restriction on the compiler is that the observable output be the same as if the comparison had taken place. (I think the compiler is also allowed to assume that the loop terminates sometime, and move code below the loop above it, and things like that.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329
0

Let's suppose we have some valid condition and compiler generated code for it.HOW OFTEN it will check it?That's the question.

At each loop if there's no optimization, never if there's optimization and the compiler understands that your condition won't change.

Gui13
  • 12,993
  • 17
  • 57
  • 104
0

How the compiler translates this isn't relevant to C or C++, as long as it works. If the compiler can see that your loop doesn't need to be run at all, it can remove it. It may unroll the loop and remove all but the first check altogether. It all depends on the compiler and the code, and there is no single answer.

If the compiler does no optimisation at all, it'll do as the standard requires - one check at the start of each iteration.

teppic
  • 8,039
  • 2
  • 24
  • 37