Can I replace an if-statement with AND?

Admin 1
Viewed 227

My prof once said, that if-statements are rather slow and should be avoided as much as possible. I'm making a game in OpenGL, where I need a lot of them. In my tests replacing an if-statement with AND via short-circuiting worked, but is it faster?

bool doSomething();

int main()
{

  int randomNumber = std::rand() % 10;

  randomNumber == 5 && doSomething();

  return 0;
}

bool doSomething()
{
    std::cout << "function executed" << std::endl;

    return true;
}

My intention is to use this inside the draw function of my renderer. My models are supposed to have flags, if a flag is true, a certain function should execute.

if-statement logical-operators c++
2 Answers

if-statements are rather slow and should be avoided as much as possible.

This is wrong and/or misleading. Most simplified statements about slowness of a program are wrong. There's probably something wrong with this answer too.

C++ statements don't have a speed that can be attributed to them. It's the speed of the compiled program that matters. And that consists of assembly language instructions; not of C++ statements.

What would probably be more correct is to say that branch instructions can be relatively slow (on modern, superscalar CPU architectures) (when the branch cannot be predicted well) (depending on what you are comparing to; there are many things that are much more expensive).

randomNumber == 5 && doSomething();

An if-statement is often compiled into a program that uses a branch instruction. A short-circuiting logical-and operation is also often compiled into a program that uses a branch instruction. Replacing if-statement with a logical-and operator is not a magic bullet that makes the program faster.

If you were to compare the program produced by the logical-and and the corresponding program where it is replaced with if (randomNumber == 5), you would find that the optimiser sees through your trick and produces the same assembly in both cases.

My models are supposed to have flags, if a flag is true, a certain function should execute.

In order to avoid the branch, you must change the premise. Instead of iterating through a sequence of all models, checking flag, and conditionally calling a function, you could create a sequence of all models for which the function should be called, iterate that, and call the function unconditionally -> no branching. Is this alternative faster? There is certainly some overhead of maintaining the data structure and the branch predictor may have made this unnecessary. Only way to know for sure is to measure the program.

user_20793030

I agree with the comments above that in almost all practical cases, it's OK to use ifs as much as you need without hesitation.
I also agree that it is not an issue important for a beginner to waste energy on optimizing, and that using logical operators will likely to emit code similar to ifs.

However - there is a valid issue here related to branching in general, so those who are interested are welcome to read on.

Modern CPUs use what we call Instruction pipelining.
Without getting too deap into the technical details:
Within each CPU core there is a level of parallelism. Each assembly instruction is composed of several stages, and while the current instruction is executed, the next instructions are prepared to a certain degree. This is called instruction pipelining.
This concept is broken with any kind of branching in general, and conditionals (ifs) in particular.
It's true that there is a mechanism of branch prediction, but it works only to some extent.

So although in most cases ifs are totally OK, there are cases it should be taken into account. As always when it comes to optimizations, one should carefully profile.

Take the following piece of code as an example (similar things are common in image processing and other implementations):

unsigned char * pData = ...; // get data from somewhere
int dataSize = 100000000; // something big
bool cond = ...;    // initialize some condition for relevant for all data
for (int i = 0; i < dataSize; ++i, ++pData)
{
    if (cond)
    {
        *pData = 2; // imagine some small calculation
    }
    else
    {
        *pData = 3; // imagine some other small calculation
    }
}

It might be better to do it like this (even though it contains duplication which is evil from software engineering point of view):

if (cond)
{
    for (int i = 0; i < dataSize; ++i, ++pData)
    {
        *pData = 2; // imagine some small calculation
    }
}
else
{
    for (int i = 0; i < dataSize; ++i, ++pData)
    {
        *pData = 3; // imagine some other small calculation
    }
}

We still have an if but it's causing to branch potentially only once.

In certain [rare] cases (requires profiling as mentioned above) it will be more efficient to do even something like this:

for (int i = 0; i < dataSize; ++i, ++pData)
{
    *pData = (2 * cond + 3 * (!cond));  
}

I know it's not common , but I encountered specific HW some years ago on which the cost of 2 multiplications and 1 addition with negation was less than the cost of branching (due to reset of instruction pipeline). Also this "trick" supports using different condition values for different parts of the data.

Bottom line: ifs are usually OK, but it's good to be aware that sometimes there is a cost.

user_185199210
Related