conditional operator good for optimization?

[mhoover]

I'm trying to remove branches from my code so it consumes less %cpu.

If I convert an inner loop if statement from:

if ( b ) {
 a = c;
} else {
 a = d;
}

if ( b ) {
 a = c;
} else {
 a = d;
}

To copy to clipboard, switch view to plain text mode 

To:

a = b ? c : d

a = b ? c : d

To copy to clipboard, switch view to plain text mode 

Does that take a branch out of the opcode?

Initial tests indicate this does not reduce the %cpu of my app very much.

[squidge]

Its still a branch regardless of which way you put it, unless your target CPU supports conditional execution of opcodes, such as ARM (in which case, both still get the same result as the first could be done via conditional execution also).

Sometimes operations can be done without branching, like the common r = (x < y) ? x : y can be done as r = y ^ ((x ^ y) & -(x < y)) but then you would have to check to ensure the extra intructions are faster than the branch in the previous code. Also, without a comment, you might not understand the second code is the same as the first, so for code maintainability, you should always use the former unless you have a real good reason to the later.

[wysota]

To add to what was already said, many architectures support branch prediction, i.e. ways of marking which of the branches is most likely to happen so that the resulting code and execution is better suited to the most common situation - that is if "b" is likely to be true, the processor can start loading code from the positive branch before the value of expression "b" is even evaluated.

For example for gcc:

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)
 
if(likely(b)) {
  a = c;
} else {
  a = d;
}

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)

if(likely(b)) {
  a = c;
} else {
  a = d;
}

To copy to clipboard, switch view to plain text mode 

[mhoover]

Thanks squidge and wysota.

I feel like I learned something.

---

Added after 1 51 minutes:

I found it interesting that the gcc websites say programmers are notoriously bad at predicting which branches are most likely to get called.

I had a function that went through an enormous amount of pixels to find the highest and lowest intensities. I did something like:

if (unlikely(pix_value > last_highest))
last_highest = pix_value;

And this increased my %cpu from 39 to 44! When I switched the "unlikely" to "likely" it dropped to about 37%. So I guess I am a poor judge.

Later I removed the __builtin_expect stuff and used the -fprofile-arcs flag to get it down to 35 %cpu.

[pkohut]

I'm trying to remove branches from my code so it consumes less %cpu.

if ( b ) {
 a = c;
} else {
 a = d;
}

if ( b ) {
 a = c;
} else {
 a = d;
}

To copy to clipboard, switch view to plain text mode 

Preload variable a before the if statement -

a = d;
if(b)
  a = c;

a = d;
if(b)
  a = c;

To copy to clipboard, switch view to plain text mode 

[wysota]

I had a function that went through an enormous amount of pixels to find the highest and lowest intensities. I did something like:

if (unlikely(pix_value > last_highest))
last_highest = pix_value;

Why would this be unlikely? Basically the probability that the next pixel has a higher value is equal to the probability it has a lower value. Using likely/unlikely is ok when you are testing a condition that you are sure is very likely or very unlikely to happen. If probabilities are more or less equal (say 40/60), there is no point in doing that.