code optimization- Removing if .. else conditions in for loops

[Kunal]

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.
However, I havent found any document confirming my belief !
Any comments, suggestions or references will be a big help !

Thanks & Regards

[Ben Pfaff]

"Kunal" <ku*************@gmail.com> writes:

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

The only way you can find out whether this makes a difference is
by measuring. My guess is that it will make no difference with
most compilers.

Note that the evaluation of `a > b' may itself require a branch.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Keith Thompson]

"Kunal" <ku*************@gmail.com> writes:

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.
However, I havent found any document confirming my belief !
Any comments, suggestions or references will be a big help !

You're assuming that the code generated for (a > B) won't involve any
conditional branches.

Any decent compiler is likely to generate similar or identical code
for both forms.

It's usually best to write your code as clearly as possible and let
the compiler worry about micro-optimization. Attempting to do
low-level optimization yourself is likely to make the compiler's job
more difficult.

First rule of optimization: Don't do it.
Second rule of optimization (advanced users only): Don't do it yet.

If you really need to do this kind of micro-optimization, perhaps
because the loop is in a performance-critical part of your program
(because you've measured it), you can probably examine the assembly
language generated by your compiler -- or you can write the code in
assembly language yourself.

--
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.

[Christian Bau]

In article <11**********************@g14g2000cwa.googlegroups .com>,
"Kunal" <ku*************@gmail.com> wrote:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.

Did you measure how long it takes?

The most important rule of optimisation: Don't optimise until you have
measured it.

(There are several most important rules of optimisation, this is just
one of them. I bet some more will be posted. This one always applies:
Never, ever optimise without measuring. )

[Eric Sosman]

Kunal wrote On 12/05/05 17:02,:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}
Even faster (probably):

c = (a > B) ? 999 : 0;
i = 999;
As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.
However, I havent found any document confirming my belief !
Any comments, suggestions or references will be a big help !

See Ben Pfaff's response.

--
Er*********@sun.com

[Jordan Abel]

On 2005-12-05, Eric Sosman <er*********@sun.com> wrote:

Kunal wrote On 12/05/05 17:02,:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

Even faster (probably):

c = (a > B) ? 999 : 0;
i = 999;

Though presumably he was doing more in the loop, you're correct.

[Eric Sosman]

Jordan Abel wrote On 12/05/05 18:00,:

On 2005-12-05, Eric Sosman <er*********@sun.com> wrote:

Kunal wrote On 12/05/05 17:02,:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

Even faster (probably):

c = (a > B) ? 999 : 0;
i = 999;

Though presumably he was doing more in the loop, you're correct.

That was the point I was trying to make, indirectly:
It's silly to micro-optimize pseudocode. If the O.P.
responds to my tongue-in-cheek suggestion by showing us
what's actually going on in the loop, we might have some
better ideas about how to optimize it -- or whether it's
even worth the bother.

--
Er*********@sun.com

[Mark McIntyre]

On 5 Dec 2005 14:02:46 -0800, in comp.lang.c , "Kunal"
<ku*************@gmail.com> wrote:

Hello,

I need help in removing if ..else conditions inside for loops.
Why - have you proved that they're inefficient?
c += (a > B) ; As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.

This would be /highly/ hardware specific, and depend very very much on
your compiler's efficiency.

As a general rule its a bad idea to try to outsmart your compiler,
until and unless you can prove its inefficient. You may end up simply
making your code slower. A good compiler might realise it could unroll
the loop and discard a whole bunch of the ifs, and your 'improvement'
might prevent that for some reason.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Flash Gordon]

Kunal wrote:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Have you tested the code to see if it is too slow? Have you done
profiling to see where the code is spending its time? Have you made sure
that you are using an efficient algorithm? All these things should come
before spending time on a question like this.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.
Anything like that is highly specific to the processor, compiler,
specific version of the compiler, the settings of the compiler and the
surrounding code.
However, I havent found any document confirming my belief !
It is very unlikely there is *any* documentation that will tell you
which is faster, since it might depend on a hole host of things.
Any comments, suggestions or references will be a big help !

Rule one of optimisation:
Don't do it.

Write the code to do the right thing in an understandable (to a human)
manner and let the optimiser that is almost certainly part of your
compiler package do its job.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Chris Dollin]

Kunal wrote:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.

On the ARM, a natural way to compile the if (assuming variables in
registers, which is plausible here) is:

CMP a, B
ADDEQ c, c, #1

Two instructions, no pipeline break. I can't see a compiler generating
better code for your `c += (a > B)` statement, and it would be easy for
it to generate much /worse/ code.

Morals: (a) measure before you consider optimising; (b) straightforward
code plays to the compiler's strengths.

--
Chris "another virtual machine" Dollin
"Certainly the absence of a smiley is not a syntax error or a constraint
violation, and therefore doesn't require a diagnostic." (Richard
Heathfield)

[Kunal]

Hello,
Thanks for all your responses.

The example I had given is a typical (but not exact) one which I have
encountered during the development of the code.
I am working on development of video compression algorithm and have
encountered deep nested loops with embedded if ... else conditions,
typically like the one I have given in the example.

I have a stiff target to meet on fps (frame per second) front and hence
I am trying to remove such conditions where there may be pipeline
stalls. So optimization is inevitable.

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

[Ben Pfaff]

"Kunal" <ku*************@gmail.com> writes:

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

Because, given the machine's instruction set, that may be the
fastest or shortest way to evaluate the boolean expression. Many
machines provide "jump if <condition>" instructions, but not "set
0/1 based on <condition>" instructions.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Joe Wright]

Kunal wrote:

Hello,
Thanks for all your responses.

The example I had given is a typical (but not exact) one which I have
encountered during the development of the code.
I am working on development of video compression algorithm and have
encountered deep nested loops with embedded if ... else conditions,
typically like the one I have given in the example.

I have a stiff target to meet on fps (frame per second) front and hence
I am trying to remove such conditions where there may be pipeline
stalls. So optimization is inevitable.

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

Because that's what computers do. Solving a boolean results in a
conditional branch (or jump or call, whatever).

C's if/else constructs are not expensive as a rule. Deeply nested loops,
poorly designed, can drag you to a stop. Algorithm failure.

As programmers we should concern ourselves with the algorithms which
solve our problems. It is a waste of our time, and rather arrogant of
most of us, to try to optimize lagnuage constructs like if, else, while,
etc. because the guys and girls who wrote the compiler know that stuff
better than we do. We design and code the algorithm. Leave code
optimization to the compiler.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Skarmander]

Ben Pfaff wrote:

"Kunal" <ku*************@gmail.com> writes:

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

Because, given the machine's instruction set, that may be the
fastest or shortest way to evaluate the boolean expression. Many
machines provide "jump if <condition>" instructions, but not "set
0/1 based on <condition>" instructions.

And even those that do might have to allocate a new register to store the
evaluated result in, which could be costlier overall.

S.

[Keith Thompson]

"Kunal" <ku*************@gmail.com> writes:

Thanks for all your responses.
To what? Please read <http://cfaj.freeshell.org/google/>.

[...]
I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

As in
c += (a > B);
as opposed to the equivalent
if (a > B)
c++;
}

If you're familiar with the assembly language of whatever CPU you
happen to be using, try writing your own code to implement the first
assignment. If the CPU provides an instruction that compares two
values and stores a 0 or 1 depending on the result, the compiler is
likely to use it. If not, a conditional branch may well be the best
way to accomplish it, even if it might cause a pipeline stall.

If the CPU has an instruction that could do the job efficiently and
it's not using it (when you specify the maximum level of
optimization), you might consider complaining to the compiler vendor.

It's really not a C language issue. As long as the generated code
gets the right answer, the C standard is happy.

Note that the results of equality and relational operators are
*usually* used as conditions rather than to produce an actual 0 or 1
value. Because of this, the authors of your compiler might reasonably
not have bothered spending much time on optimizing this kind of thing.

--
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.

[Christian Bau]

In article <11**********************@f14g2000cwb.googlegroups .com>,
"Kunal" <ku*************@gmail.com> wrote:

Hello,
Thanks for all your responses.

The example I had given is a typical (but not exact) one which I have
encountered during the development of the code.
I am working on development of video compression algorithm and have
encountered deep nested loops with embedded if ... else conditions,
typically like the one I have given in the example.

I have a stiff target to meet on fps (frame per second) front and hence
I am trying to remove such conditions where there may be pipeline
stalls. So optimization is inevitable.

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

Just curious: You do that just for entertainment or for the learning
experience, or is someone actually employing programmers who try to
learn about optimisation by posting on comp.lang.c to implement video
compression algorithms?

[Carl R. Davies]

Kunal wrote:

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Could you remove the if from the loop:

loop( condition )
if( something )
stuff
else
other stuff
end loop
if( something )
loop (condition)
stuff
end loop
else
loop( condition )
stuff
end loop
endif

[Eric Sosman]

Joe Wright wrote:

Kunal wrote:

Hello,
Thanks for all your responses.

The example I had given is a typical (but not exact) one which I have
encountered during the development of the code.
I am working on development of video compression algorithm and have
encountered deep nested loops with embedded if ... else conditions,
typically like the one I have given in the example.

I have a stiff target to meet on fps (frame per second) front and hence
I am trying to remove such conditions where there may be pipeline
stalls. So optimization is inevitable.

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

Because that's what computers do. Solving a boolean results in a
conditional branch (or jump or call, whatever).

C's if/else constructs are not expensive as a rule. Deeply nested loops,
poorly designed, can drag you to a stop. Algorithm failure.

As programmers we should concern ourselves with the algorithms which
solve our problems. It is a waste of our time, and rather arrogant of
most of us, to try to optimize lagnuage constructs like if, else, while,
etc. because the guys and girls who wrote the compiler know that stuff
better than we do. We design and code the algorithm. Leave code
optimization to the compiler.

Kunal did mention that he's subject to tight performance
requirements. If good algorithms have been chosen and the
unaided compiler still can't meet the performance specs, it
may well be time to micro-optimize.

Two important points, though: First, he MUST measure to
isolate the cause(s) of the failure to perform fast enough.
If the loop takes one percent of the total time and he gets
it to run ten thousand times faster than it does now, he'll
have made less than a one percent improvement in the program
as a whole. Second, the gains from micro-optimization are
usually rather modest: You can seldom expect to get dramatic
speedups from the kind of transformation Kunal is considering.
If Kunal's program is just a whisker too slow, fiddling with
the `if' has a chance of boosting the speed just enough --
but if the program is now running at only half the required
speed, this sort of thing is surpassingly unlikely to help.

Sure, counter-examples to the second point exist -- but the
big gains usually stem from things like arranging the data in
ways that are friendly to the machine's caches, issuing pre-
fetches for data that'll be needed several instructions further
along, and a lot of other such implementation-specific techniques
that really have no "image" in the C language as such. If such
shenanigans are needed, Kunal needs to consult people who are
experts on his system.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Richard Tobin]

In article <11**********************@f14g2000cwb.googlegroups .com>,
Kunal <ku*************@gmail.com> wrote:

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

As you know, "A > B" means "1 if A > B and 0 otherwise". It may well
be that to get the right one of those values - 1 or 0 - the quickest
way is to test and branch.

Of course, it may not be. Depending on the instruction set, there may
be a direct way to get 1 or 0 in a register according to the result of
the comparison. But if you can see a simple transformation of your
code that allows this, then very likely the compiler can too.

The only way is to try it and see, and remember that it won't
necessarily be better on other processors.

-- Richard

[Ed Prochak]

Keith Thompson wrote:

"Kunal" <ku*************@gmail.com> writes:

Thanks for all your responses.

To what? Please read <http://cfaj.freeshell.org/google/>.

[...]

I am still not clear why would the compiler generate a branch condition
if only a boolean expression is to be solved.

As in
c += (a > B);
as opposed to the equivalent
if (a > B)
c++;
}

If you're familiar with the assembly language of whatever CPU you
happen to be using, try writing your own code to implement the first
assignment. If the CPU provides an instruction that compares two
values and stores a 0 or 1 depending on the result, the compiler is
likely to use it. If not, a conditional branch may well be the best
way to accomplish it, even if it might cause a pipeline stall.

If the CPU has an instruction that could do the job efficiently and
it's not using it (when you specify the maximum level of
optimization), you might consider complaining to the compiler vendor.

It's really not a C language issue. As long as the generated code
gets the right answer, the C standard is happy.

Actually, does the C standard now require a true expression result to
be 1?
(sorry, but I still think of C in terms of the original K&R, where 0 is
false and anything else is true. And I've done enough assembler
programming to know the compare doesn't simply result in a 1 in a
usable register.)

Ed

[Jordan Abel]

On 2005-12-07, Ed Prochak <ed********@magicinterface.com> wrote:

Keith Thompson wrote:

"Kunal" <ku*************@gmail.com> writes:

> Thanks for all your responses.

To what? Please read <http://cfaj.freeshell.org/google/>.

[...]

> I am still not clear why would the compiler generate a branch condition
> if only a boolean expression is to be solved.

As in
c += (a > B);
as opposed to the equivalent
if (a > B)
c++;
}

If you're familiar with the assembly language of whatever CPU you
happen to be using, try writing your own code to implement the first
assignment. If the CPU provides an instruction that compares two
values and stores a 0 or 1 depending on the result, the compiler is
likely to use it. If not, a conditional branch may well be the best
way to accomplish it, even if it might cause a pipeline stall.

If the CPU has an instruction that could do the job efficiently and
it's not using it (when you specify the maximum level of
optimization), you might consider complaining to the compiler vendor.

It's really not a C language issue. As long as the generated code
gets the right answer, the C standard is happy.

Actually, does the C standard now require a true expression result to
be 1?
(sorry, but I still think of C in terms of the original K&R, where 0 is
false and anything else is true. And I've done enough assembler
programming to know the compare doesn't simply result in a 1 in a
usable register.)

the "as if" rule will let you weasel out of it in most cases for a real
implementation, but if you assign the result of a relational/equality
comparison expression to an integer variable, it must be 1 for true, 0
for false.

[Keith Thompson]

"Ed Prochak" <ed********@magicinterface.com> writes:

Keith Thompson wrote:

"Kunal" <ku*************@gmail.com> writes:

> Thanks for all your responses.
To what? Please read <http://cfaj.freeshell.org/google/>.

[...]

> I am still not clear why would the compiler generate a branch condition
> if only a boolean expression is to be solved.

As in
c += (a > B);
as opposed to the equivalent
if (a > B)
c++;
}

If you're familiar with the assembly language of whatever CPU you
happen to be using, try writing your own code to implement the first
assignment. If the CPU provides an instruction that compares two
values and stores a 0 or 1 depending on the result, the compiler is
likely to use it. If not, a conditional branch may well be the best
way to accomplish it, even if it might cause a pipeline stall.

If the CPU has an instruction that could do the job efficiently and
it's not using it (when you specify the maximum level of
optimization), you might consider complaining to the compiler vendor.

It's really not a C language issue. As long as the generated code
gets the right answer, the C standard is happy.

Actually, does the C standard now require a true expression result to
be 1?

It depends on the expression.

The result of any operator that yields a boolean result is required to
be 0 for false, 1 for true; this applies to relational operators,
equality operators, unary "!", and probably others I haven't thought
of. The statement
c += (a > B);
is guaranteed to add either 0 or 1 to c; if it adds 2, the compiler is
broken (or you've invoked undefined behavior somewhere).

The is*() functions in <ctype.h> may return any non-zero value if the
corresponding condition is true. The statement
c += isdigit(x);
is unlikely to do what you want it to. If you specifically want to
add 0 or 1, you can do
c += !!isdigit(x);
or any of a number of other workarounds.

If an expression is used as a condition, it's treated as false if it
compares equal to 0, true otherwise.
(sorry, but I still think of C in terms of the original K&R, where 0 is
false and anything else is true.
That hasn't changed -- nor has the fact that *some* boolean
expressions are guaranteed to evaluate to either 0 or 1. (I *think*
K&R1 guaranteed this, but I don't have my copy here.)
And I've done enough assembler
programming to know the compare doesn't simply result in a 1 in a
usable register.)

That depends on the CPU. If a comparison doesn't result in a 0 or 1
in a usable register, the compiler will have to go to some extra
effort to generate the 0 or 1 value, unless it can legally optimize
out the result. For example, given

if (x == y) { ... } else { ... }

the expression "x == y" yields a value of 0 or 1, but the generated
code doesn't have to store this value anywhere as long as executes the
correct block of code.

--
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.

[websnarf]

Kunal wrote:

Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++) {
if (a > B) c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++) {
c += (a > B) ;
}

For most compilers the two are exactly the same.

But a more importantly real savings come from doing more serious
optimizations like this:

if (a > B) {
for (i=0; i < 999; i++) c++;
}

which is equivalent to:

c += 999 * (a > B);

Of course if your compiler is good enough, it can figure all this out
as well.

Seriously though, if you want to remove branched from the inside of a
loop, hoisting is usually the best way, when it is available. If a
and/or B is really a macro that makes it a function of i, or itself, or
something like that, then it will depend on how they expand out.

Unfortunately the ANSI C standard is basically broken on the right
shift operator, but on most compilers, if you know a and B are signed
ints and positive you have certain functional tricks like:

(a > B)

is the same as:

- ((B - a) >> (sizeof (int) * CHAR_BIT - 1))

which does remove the branch pretty much for sure. But as I said, the
ANSI C standard doesn't allow you to assume that the two are same when
a and B are positive (they are on > 99.999% of compilers deployed.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Kunal]

like I said in my earlier post, the if conditions are embedded deep
inside multiple for loops. Hence such an opportunity has rarely
occurred .... and whenever it has, this technique has been used.

[Naren]

Elementary optimizations like this should be left to compiler only and
should not be done at the cost of code clarity and readability.
Moreover original code seems to be more optimized than the modified
code if compiler optimization is kept aside. Original code increments
only if condition is satisfied while modified code does both operations
(checking condition and doing addition) and always. One more
optimization can be done by doing a pre-increment both inside for loop
as well as inside the block if post increment is not really required.

thanks
--naren

Kunal wrote:

Hello,

I need help in removing if ..else conditions inside for loops. I have
used the following method but I am not sure whether it has actually
helped.
Below is an example to illustrate what I have used.
Original code :

c= 0 ;
for (i=0; i<999; i++)
{
if (a > B)
c++ ;
}

Modified code for speed optimization

c= 0 ;
for (i=0; i<999; i++)
{
c += (a > B) ;
}

As per my reasoning, the logical expression is evaluated but no
conditional branching instructions should be generated. This should
avoid any pipeline stalls.
However, I havent found any document confirming my belief !
Any comments, suggestions or references will be a big help !

Thanks & Regards