break statement in a for loop

[Keith Thompson]

christian.bau schreef:

Boy, oh boy... I thought there would be some intelligent people here
who would know what an inserted break in such a loop actually would
result in in assemled code. That was the whole objective of the
question.

I'm not interested in answers trying to tell me that an example I
gave to clarify the -structural- problem is not a sensible program
or is bad code or that I do not follow holy standards. It's not
about the code, the question is about what an inserted break in any
loop (that is not optimized away of course in the real program, I'm
not that stupid, but I assumed some smartness of the reader here)
actually inserts in the assembled code. Actually, to just give you
an example, not even all code in K&R is sensible code, but allas.

C99 6.8.6.3p2:

A break statement terminates execution of the smallest enclosing
switch or iteration statement.

That is quite simply *all* we can tell you here. If you're asking
about what assembly or machine code will be generated, that's not a
question about C, and we can't answer it.

Since I will not and cannot display to you the full code I'll find
out myself what is happening. Anyway, thanks for the fish and the
(few) sensible answers.

The code you deleted when you posted your example was probably
critical to answering your question. I'm not sure what you expected
us to tell you.

 

[a.mil]

Hmm, at least now I get sensible answers

To give a short corrolary: I turned off optimization, assured myself
the loop made sense and could not be "optimized" away (if any
optimization at all) but still the "break" made the code slower than
without.
Anyway, I got some good ideas through this interaction, so thanks for
the fish And the chips!

 

[Richard Tobin]

To give a short corrolary: I turned off optimization, assured myself
the loop made sense and could not be "optimized" away (if any
optimization at all) but still the "break" made the code slower than
without.

If you really want to know what's happening, look at the assembly
code. Most compilers can show it to you (for example, on unix systems
"cc -S" will generate a .s file containing the assembly code). Even
if you're not familiar with the processor's assembly language, you can
usually recognise the loops. Compare the output with and without
optimisation. If you're using GCC, there are hundreds of switches to
disable specific optimisations so you can narrow it down further.

-- Richard

 

[Bart van Ingen Schenau]

I am programming for code-speed, not for ansi or other nice-guy stuff
and I encountered the following problem:

When I have a for loop like this:

b=b0;
for (a=0,i=0;i<100;i++,b--) {
if (b%i) continue;
a=1;
}

I want to break out of the loop -fast- after a==1. When I put a break
after it like in

b=b0;
for (a=0,i=0;i<100;i++,b--) {
if (b%i) continue;
a=1;
break;
}

the former fast loop turns into a horribly (factor 100 or so...) slow
one, so better to use no break at all in my opinion.

Does anyone know exactly -why- the break statement makes the loop so
slow??

The only ones who can give a definitive answer to that question are the
authors of your compiler (or rather, its optimiser).

Isn't it just an extra "jmp" in assembler equivalent code?

Before the optimiser gets his hands on the code, that (or whatever
equivalent the compiler uses internally) is probably what gets
generated for the break statement.

I compared
both assembled outputs with and without the break statement, but they
really look quite different.. ?! I optimize with -O3 using gcc.

But all kinds of strange stings will happen to the code when the
optimiser tries to squeeze every last microsecond out of it.
What most likely happened is that with the extra break statement, the
optimiser did no longer recognise the loop as something it could work
with. Therefor, the loop was no longer being optimised.

The first rule you should learn from this is: Do not try to out-smart
your compiler. You will likely end-up with worse results.
Optimisers typically work best with idiomatically written code, because
that will give the best results for the largest percentage of
customers/users.
Therefor, the basic rules for writing the fastest code are:
1. Write clear, understandable code. Do not try to outsmart your
compiler.
2. If the result is not fast enough, profile the code, to see where the
bottlenecks are.
3. Try to find a more efficient algorithm for each bottleneck.
4. Only if you have the most efficient algorithm, start looking at the
implementation.
5. When you make a change, verify that it is actually an improvement. If
not, revert the change.

Bart v Ingen Schenau

 

[christian.bau]

Boy, oh boy... I thought there would be some intelligent people here
who would
know what an inserted break in such a loop actually would result in in
assemled
code. That was the whole objective of the question.

I'm not interested in answers
trying to tell me that an example I gave to clarify the -structural-
problem is not
a sensible program or is bad code or that I do not follow holy
standards. It's not
about the code, the question is about what an inserted break in any
loop (that is
not optimized away of course in the real program, I'm not that stupid,
but I assumed
some smartness of the reader here) actually inserts in the assembled
code.

Doesn't look to me as if you are the brightest bulb, and your disdain
for "holy standards" is what bites you in the arse.

Your code is pointless: Not from any aesthetical point of you (like a
program printing the prime numbers up to one million could be called
pointless) but from the point of view of the C language: A function
that calculates some results but never prints them, never uses them,
never reports them to the outside world, is pointless on the level of
the programming language and can therefore be optimised away. This is
exactly what happened to your code. And the more optimisations the
compiler uses, the more will it bite you when your view of the C
language is not the same as that of the C standard.

 

[Francine.Neary]

(e-mail address removed) said:








The same result can be achieved much more quickly:

int main(void)
{
return 0;

}

Why do optimizations like that by hand when the compiler can do them
for you?