Order of statements using if

[aeismail]

Hi, everybody:

A quick question regarding how to write if/then blocks.

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

My question comes because I want to know if there is any advantage in
writing the test condition to favor one block over the other. (For the
code I'm working with, one case is definitely preferred over the
other--at least 2 to 1.)

Thanks,

--AEI

 

[Ron AF Greve]

Hi,

I believe the x86 type of procesors expect to fall through (thus if compiled
'litterally' the if condition being true).

However if your compiler does or doesn't optimize for that one can only
guess. I would recommend to just try it (and still then it might depend on
the condition).


Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[Neelesh Bodas]

Hi, everybody:

A quick question regarding how to write if/then blocks.

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

My question comes because I want to know if there is any advantage in
writing the test condition to favor one block over the other. (For the
code I'm working with, one case is definitely preferred over the
other--at least 2 to 1.)

The exact implementation of if-else construct is not specified by the
standard, and hence the answer would vary depending on the platform
and implementation. In other words, trying to write if-else clause
based on certain heuristic might not help if you are writing code that
runs across platforms and implementations.

-N

 

[Michal Nazarewicz]

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

My question comes because I want to know if there is any advantage in
writing the test condition to favor one block over the other. (For the
code I'm working with, one case is definitely preferred over the
other--at least 2 to 1.)

You should ask on group regarding your compiler. If I had to guess I'd
say that you should put block which is most likely to be executed first,
however consult your compiler's documentation if you cannot turn
profiling on.

 

[Eric Johnson]

Another thing to consider is that modern CPUs perform branch
prediction, so it might not really matter that much whether your
compiler optimizes in a certain particular way. From what I
understand the branch prediction in hardware is quite good these
days. Check out this article for more info:

http://en.wikipedia.org/wiki/Branch_prediction

 

[Michal Nazarewicz]

Another thing to consider is that modern CPUs perform branch
prediction, so it might not really matter that much whether your
compiler optimizes in a certain particular way.

Yep, when code is run for the first time processor has no data about
execution of code and branches taken previously so it can only guess.
In x86 the guess is as follows: If the branch is forward it is guessed
not to be taken and if the branch is backward it is guessed to be taken.

 

[Michael Angelo Ravera]

Another thing to consider is that modern CPUs perform branch
prediction, so it might not really matter that much whether your
compiler optimizes in a certain particular way. From what I
understand the branch prediction in hardware is quite good these
days. Check out this article for more info:

http://en.wikipedia.org/wiki/Branch_prediction

If there is code following both the "if" and the "else" case, there
has to be a branch to the common following code from the "if"
alternative and a branch "to" the conditional code for the "else"
alternative (maybe no branch to the common code, however).

If, however, there are a number of tests, the most common would be
most efficiently first.

So, if there is code following and only two alternatives and the the
excecution paths rejoin, there is likey to be no difference at all.

 

[Michal Nazarewicz]

If there is code following both the "if" and the "else" case, there
has to be a branch to the common following code from the "if"
alternative and a branch "to" the conditional code for the "else"
alternative (maybe no branch to the common code, however).

But the branch in the "if part" is unconditional and as such does not
need a branch prediction.

If, however, there are a number of tests, the most common would be
most efficiently first.

So, if there is code following and only two alternatives and the the
excecution paths rejoin, there is likey to be no difference at all.

There is, as conditional jumps are those that make the difference.

 

[James Kanze]

A quick question regarding how to write if/then blocks.

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

Why? Does your profiler say that this is causing a bottleneck
in your code?

My question comes because I want to know if there is any advantage in
writing the test condition to favor one block over the other. (For the
code I'm working with, one case is definitely preferred over the
other--at least 2 to 1.)

The usual rule is to write the shorter block first, provided
that this doesn't make the conditional expression harder to
read. Worrying about performance in this sort of thing is a
total waste of time.

 

[aeismail]

Why? Does your profiler say that this is causing a bottleneck
in your code?

Well, the code I was using runs about twice as fast before I inserted
the block into the code, so it's a pretty good clue that the if block
is part of the bottleneck.

The usual rule is to write the shorter block first, provided
that this doesn't make the conditional expression harder to
read. Worrying about performance in this sort of thing is a
total waste of time.

Normally, I'd agree with you. But in this particular case, it's for
use in a scientific code. The code will pass through this if loop on
the order of billions of times during the course of the runs. Even a 1
percent speed-up will equal thousands of CPU hours. (Hence the
question.)

However, since it's apparently a compiler-dependent issue, I'll see
how it's handled for the machines I'm running on. (Thanks to everyone
for their comments.)

--AEI

 

[Jim Langston]

Hi, everybody:

A quick question regarding how to write if/then blocks.

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

My question comes because I want to know if there is any advantage in
writing the test condition to favor one block over the other. (For the
code I'm working with, one case is definitely preferred over the
other--at least 2 to 1.)

consider a large if.. else block
if ( a )
// do
else if ( b )
// do
else if ( c)
// do
else if ( d )
// do
else
// do

Normally they are quite fast, but if cycles are tight you want to ensure
that condition a will happen more than b, b more than the rest, etc...

For the program to check condition d, it will have had to check a,b and c.
If the conditional check is trivial it usually doesn't matter, a cycle or
two. If it is a more complicated conditional check then it can matter a
lot. A switch statement can be more effecient since it becomes pretty much
just a jump table, but then you have to be able to have an ordinal value to
check, which is not always possible.

Usually, however, people don't need to concern themselves with the
effecientcy of if else blocks as they don't take that much time. If you've
found that this is your bottle neck, the first thing to do is make sure the
conditions that happen most are at the top.

 

[Jerry Coffin]

[ ... ]

Normally, I'd agree with you. But in this particular case, it's for
use in a scientific code. The code will pass through this if loop on
the order of billions of times during the course of the runs. Even a 1
percent speed-up will equal thousands of CPU hours. (Hence the
question.)

Under these circumstances, it would be imminently worthwhile to see if
there's any reaonable way to move the if out of the loop entirely (e.g.
by splitting into two separate loops). Of course, to help with that,
we'd need to see the code for the loop, or at least a solid description
of what it does. Of course, it's not always possible to accomplish that,
but it's worth looking into.

 

[Scott Gifford]

Hi, everybody:

A quick question regarding how to write if/then blocks.

Do C++ compilers care in terms of execution (i.e., efficiency) which
block in an if/then/else loop is executed? That is, will going to the
"else" block be less efficient than using the "then" block?

Some compilers have an option to optimize the code depending on how
often particular branches are taken. In g++, you can use the
"-fprofile-arcs" option to instrument your code, run it on some sample
data to generate statistics, then re-compile with
"-fbranch-probabilities" to give the compiler a hint about how often
the various branches are taken. I haven't tried this, but I've heard
it gives a speedup in some cases. Perhaps your compiler has similar
options you could try.

Good luck!

---Scott.

 

[James Kanze]

Well, the code I was using runs about twice as fast before I
inserted the block into the code, so it's a pretty good clue
that the if block is part of the bottleneck.

Maybe, but that could be simply the time necessary to evaluate
the condition.

Normally, I'd agree with you. But in this particular case,
it's for use in a scientific code. The code will pass through
this if loop on the order of billions of times during the
course of the runs. Even a 1 percent speed-up will equal
thousands of CPU hours. (Hence the question.)

My point was more that for this sort of thing, the compiler
should be able to handle whatever optimization is possible.

Back in the old days, when I was working in assembler, we'd
sometimes "out of line" the exceptional case of the if,
organizing the assembler something like:

loop {
// ...
if ( condition ) goto ExceptionalCase ;
// normal case...
EndCondition:
// ...
}
// ...
ExceptionalCase:
// ...
goto EndCondition ;

Even today (in fact, perhaps more so today), this sort of thing
can make a difference (in tight loops, of course). A good
compiler, however, should be able to pick it up, and do it for
you. (Obviously, it will need profiling information to do so.
But most modern compilers have support for profile driven
optimizations.)

If the compiler doesn't do this sort of thing automatically,
trying to reorganize the code so that it ends up with the
equivalent results will require a lot of work, and probably end
up making the code far more difficult to read. And if you leave
both branches of the if in the loop, I'd be very, very surprised
if swapping them makes a measurable difference (but it's an easy
experiment to make).