break statement in a for loop

[a.mil]

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??
Isn't it just an extra "jmp" in assembler equivalent code? I compared
both assembled outputs with and without the break statement, but they
really look quite different.. ?! I optimize with -O3 using gcc.

[klaushuotari]

On 28 huhti, 22:15, [e-mail] wrote:

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??
Isn't it just an extra "jmp" in assembler equivalent code? I compared
both assembled outputs with and without the break statement, but they
really look quite different.. ?! I optimize with -O3 using gcc.

Break statement should not inherently make branching that much slower,
while in practice it usually does.

I guess it's implementation dependent, for example in x86 it's not a
big deal.
Just make concise and clear code, and it will turn out exactly nice in
machine code level. If the compiler is intelligent enough, it should
catch this situation and make appropriate code for it. No worries.

[Richard Heathfield]

a.***@chello.nl said:

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;
}

This should be really fast, since you get a divide by zero error on the
very first time through the loop.

It is easier to make a correct program fast than to make a fast program
correct. Start off, then, by seeking correctness.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Malcolm McLean]

<a.***@chello.nlwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

>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??
Isn't it just an extra "jmp" in assembler equivalent code? I compared
both assembled outputs with and without the break statement, but they
really look quite different.. ?! I optimize with -O3 using gcc.

I think there must be some mistake elsewhere.
If the loop execution has changed by a factor of 100 then either you are not
measuring the same thing, or the compiler has optimised the loop away in
one case but not the other. An example would be if you used the value of i
later in the function but ignored a. In one case the compiler can optimise
to i = 100, in the other case it probably isn't clever enough to do it
without running through the loop.
Someone will probably point out, correctly, that a conforming compiler can
compile the break to something horribly slow. The standard makes no
guarantees on efficiency. Whilst this might account for a factor of two or
three, I cannot see how it would account for 100.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[christian.bau]

[e-mail] wrote:

I am programming for code-speed, not for ansi or other nice-guy stuff

I don't know _what_ you are programming for, but you flunked your
maths test _and_ your programming test, didn't you? (And that's me
being a nice guy, you shouldn't meet me in non-ansi mode).

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;
}

As others mentioned, undefined behavior (most likely a crash)
immediately when you calculate b % 0 in the first iteration. If you
started the loop with i = 1, then a would be set to 1 immediately,
making the whole loop rather pointless.

Now assuming that you intended to do something sensible, like starting
the loop with i = 2: Note that (b % i) != 0 is exactly the same as ((b
+ i) % i) != 0. Inside the loop, i is increased and b decreased in
each iteration, whereas b + i remains constant. So it seems that you
are just checking whether a certain number has a factor less than 100.
You can do that significantly faster by checking divisibility by prime
numbers up to 100; in practice a hardcoded

a = (b % 2 && b % 3 && b % 5 && b % 7 && b % 11 ... && b % 97) ? 0 :
1;

would be faster by a factor ten again on many implementations.

[a.mil]

Ok, this was a bad fast example, I admit.
Therefore below another example that shows the point.
int main()
{
unsigned long i,j,k,l,n;

for (l=0;l<10000000;l++) {
j=0;
k=10;
n=231;

for (i=1;n>3;j+=8,k+=j,n-=2) {
if (k%n) continue;
i=0;
break;
}
}
return 0;
}
Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!). My store on the factor 100 incorporates a lot more
code.

[Richard Heathfield]

a.***@chello.nl said:

Ok, this was a bad fast example, I admit.
Therefore below another example that shows the point.
int main()
{
unsigned long i,j,k,l,n;

for (l=0;l<10000000;l++) {
j=0;
k=10;
n=231;

for (i=1;n>3;j+=8,k+=j,n-=2) {
if (k%n) continue;
i=0;
break;
}
}
return 0;
}
Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!). My store on the factor 100 incorporates a lot more
code.

The same result can be achieved much more quickly:

int main(void)
{
return 0;
}

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[a.mil]

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".
Richard Heathfield schreef:

a.***@chello.nl said:

Ok, this was a bad fast example, I admit.
Therefore below another example that shows the point.
int main()
{
unsigned long i,j,k,l,n;

for (l=0;l<10000000;l++) {
j=0;
k=10;
n=231;

for (i=1;n>3;j+=8,k+=j,n-=2) {
if (k%n) continue;
i=0;
break;
}
}
return 0;
}
Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!). My store on the factor 100 incorporates a lot more
code.

The same result can be achieved much more quickly:

int main(void)
{
return 0;
}

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

a.***@chello.nl said:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

But break isn't the problem. The problem is a poorly-constructed
algorithm, which involves you performing many unnecessary calculations.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Default User]

a.***@chello.nl wrote:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

a.***@chello.nl wrote:

Ok, this was a bad fast example, I admit.
Therefore below another example that shows the point.
int main()
{
unsigned long i,j,k,l,n;

for (l=0;l<10000000;l++) {
j=0;
k=10;
n=231;

for (i=1;n>3;j+=8,k+=j,n-=2) {
if (k%n) continue;
i=0;
break;
}
}
return 0;
}
Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!). My store on the factor 100 incorporates a lot more
code.

On my system, without the "break", it takes 0.001 seconds (according
to "time"). That's because without the break, the compiler realises
your program does nothing and your for loop is useless, so it removes
it altogether. How about an actual demonstration (a program that does
something useful, such as printing the result of your calculation,
whatever it is you're trying to calculate)?

[Malcolm McLean]

<a.***@chello.nlwrote in message
news:11**********************@c35g2000hsg.googlegr oups.com...

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

It is perfectly reasonable to post a compileable snippet showing the
problem, but here we don't have enough to work on. It is hard to optimise a
function that doesn't actully do anything.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[CBFalconer]

Malcolm McLean wrote:

<a.***@chello.nlwrote in message

>It's not my objective to show you the full code; it's about the
issue of execution speed and "break".

It is perfectly reasonable to post a compileable snippet showing
the problem, but here we don't have enough to work on. It is hard
to optimise a function that doesn't actully do anything.

Besides which, the loop does different things with the break
inserted.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Tobin]

In article <11**********************@l77g2000hsb.googlegroups .com>,
<a.***@chello.nlwrote:

>Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!).

I get a similar result with GCC on a PPC Mac. It appears to just be
an optimisation effect: without the break the compiler can determine
enough about the inner for loop to optimise it away completely; with
the break it can't.

It's easy to construct artificial examples of this kind, but they are
rare in real programs, because if the compiler can optimise away a
loop, then the programmer probably won't write it in the first place.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[christian.bau]

On Apr 29, 8:34 am, [e-mail] wrote:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

[Malcolm McLean]

"christian.bau" <ch***********@cbau.wanadoo.co.ukwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

On Apr 29, 8:34 am, [e-mail] wrote:

>It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

That's not quite true

I would much rather write

y = x/factorial(6);

with the factorial function doing what you would expect than

y = x/FACT6;

or y = x/720;

if I could trust the compiler to optimise away the loop.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"christian.bau" <ch***********@cbau.wanadoo.co.ukwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

>On Apr 29, 8:34 am, [e-mail] wrote:

>>It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

That's not quite true

I would much rather write

y = x/factorial(6);

with the factorial function doing what you would expect than

y = x/FACT6;

or y = x/720;

if I could trust the compiler to optimise away the loop.

That's very different. In the case of the factorial() function, the
compiler can *optimize* the loop (possibly to a single literal value);
it can't *optimize away* the loop, because you use the result.

In the original code being discussed, the loop does not produce any
results. An optimizing compiler can eliminate it entirely.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[a.mil]

christian.bau schreef:

On Apr 29, 8:34 am, [e-mail] wrote:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

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.

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.

[Flash Gordon]

a.***@chello.nl wrote, On 29/04/07 22:38:

<snip>

Boy, oh boy... I thought there would be some intelligent people here

There are plenty of intelligent people.

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.

That all depends on the processor, the compiler, the options given to
the compiler, and often the surrounding code.

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

OK, so you don't care if your code is good, bad, or fundamentally
broken. In that case it should not matter what the compiler does.

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.

Well, since under some conditions the entire loop will be optimised away
if *obviously* depends on the *actual* code and the *real* situation.

Actually, to just give you an example, not even all code in K&R is
sensible code, but allas.

It makes a lot more sense than the code you have shown.

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.

If you refuse to give a sensible example people cannot sensibly guess
what a compiler will do, and in any case the impact will depend on the
compiler, the options it is given, and the processor. For example, on
some processors it will break the pipeline, other processors do not even
*have* a pipeline.
--
Flash Gordon

[Old Wolf]

On Apr 30, 9:38 am, [e-mail] wrote:

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.

This newsgroup does not deal with "assemled code"...

I do not follow holy standards.

.... nor with non-standard programs.

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

Surely you agree that code which divides by zero is not a good example
for anything?

Anyway, it's not clear to me exactly what you are asking, but if you
are
asking about the speeds of varying algorithms, then comp.programming
would be a good newsgroup to ask on.

about the code, the question is about what an inserted break in any
loop actually inserts in the assembled code.

That would depend on your compiler. Some C environments don't even
have any "assembled code". You should post this question on a
newsgroup or forum relevant to your specific compiler.

Run this without the break statement and with the break statement
and look at execution time. On my 1.5GHz P4 it takes 1.3s and
13.9s respectively (!).

Different algorithms take different lengths of time? Who'da thunk it!

It's pretty obvious that your compiler is performing some sort of
optimization, and when you change the code you get a different
optimization. Without any further information it's impossible to
provide a more accurate 'answer'. You should post on a newsgroup
relevant to your specific compiler.

[J. J. Farrell]

On Apr 29, 2:38 pm, [e-mail] wrote:

christian.bau schreef:

On Apr 29, 8:34 am, [e-mail] wrote:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

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.

Then you have very strange thought processes, or a complete
misunderstanding of how C compilers work. It obviously depends
entirely on at least the complete compilation unit, the compiler, the
target processor, and the options given to the compiler. If your code
isn't correct C, it could also depend on the phase of the moon or
anything else. The only thing which can tell you is the compiler, and
the smallest change to anything in the list above could change its
behaviour entirely.

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.

How the Hell could anyone here know, without knowledge of the entire
compilation unit and detailed knowledge of your particular compiler's
algorithms under all the conditions you're providing? It can do
anything it likes as long as the code behaves in the way that C
defines it should behave, and if the code is not valid C then all bets
are off.

[Keith Thompson]

a.***@chello.nl writes:

christian.bau schreef:

>On Apr 29, 8:34 am, [e-mail] wrote:

It's not my objective to show you the full code; it's about the issue
of execution speed and "break".

Your first example was pure nonsense invoking undefined behavior at
the first step.

Your second example was a completely useless piece of code, where huge
portions of the code could be optimised away. All that you have been
testing is the capability of the compiler to detect nonsense code and
remove it. It seems your break statement affected the compilers
capability of detecting nonsense code. This might be of importance to
you, it is of no importance to those 99.9999 percent of programmers
who actually write more sensible code in the first place.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[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]

In article <11**********************@h2g2000hsg.googlegroups. com>,
<a.***@chello.nlwrote:

>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

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Bart van Ingen Schenau]

a.***@chello.nl wrote:

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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[christian.bau]

On Apr 29, 10:38 pm, [e-mail] wrote:

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]

On Apr 29, 8:32 am, Richard Heathfield <[e-mail]:

[e-mail] said:

Ok, this was a bad fast example, I admit.
Therefore below another example that shows the point.

int main()
{
unsigned long i,j,k,l,n;

for (l=0;l<10000000;l++) {
j=0;
k=10;
n=231;

for (i=1;n>3;j+=8,k+=j,n-=2) {
if (k%n) continue;
i=0;
break;
}
}
return 0;
}

Run this without the break statement and with the break statement and
look at execution time. On my 1.5GHz P4 it takes 1.3s and 13.9s
respectively (!). My store on the factor 100 incorporates a lot more
code.

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? :)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk
email: rjh at the above domain, - www.