C++: Set bool value only if not set

16,178

Solution 1

You're almost certainly better off just using myFlag = true;.

About the best you can hope for from the if (!myFlag) myFlag = true; is that the compiler will notice that the if is irrelevant and optimize it away. In particular, the if statement needs to read the current value of myFlag. If the value isn't already in the cache, that means the instruction will stall while waiting for the data to be read from memory.

By contrast, if you just write (without testing first) the value can be written to a write queue, and then more instructions can execute immediately. You won't get a stall until/unless you read the value of myFlag (and assuming it's read reasonably soon after writing, it'll probably still be in the cache, so stalling will be minimal).

Solution 2

CPU-cycle wise, prefer myFlag = true; Think about it: even if the compiler makes no optimization (not really likely), just setting it takes one asm statement, and going through the if takes at least 1 asm statement.

So just go with the assignment.

And more importantly, don't try to make hypotheses on such low-level details, specific compiler optimizations can totally go against intuition.

Solution 3

You do realize that the check is moot right? If you blindly set it to true and it was not set, you are setting it. If it was already true, then there is no change and you are not setting it, so you effectively can implement it as:

myFlag = true;

Regarding the potential optimizations, to be able to test, the value must be in the cache, so most of the cost is already paid. On the other hand, the branch (if the compiler does not optimize the if away, which most will) can have a greater impact in performance.

Share:
16,178
ecbrodie
Author by

ecbrodie

Software Developer at Nulogy, Toronto, ON

Updated on June 04, 2022

Comments

  • ecbrodie
    ecbrodie almost 2 years

    I have code in my C++ application that generally does this:

    bool myFlag = false;
    while (/*some finite condition unrelated to myFlag*/) {
        if (...) {
            // statements, unrelated to myFlag
        } else {
            // set myFlag to true, perhaps only if it was false before?
        }
    }
    if (myFlag) {
        // Do something...
    }
    

    The question I have pertains to the else statement of my code. Basically, my loop may set the value of myFlag from false to true, based on a certain condition not being met. Never will the flag be unset from true to false. I would like to know what statement makes more sense performance-wise and perhaps if this issue is actually a non-issue due to compiler optimization.

    myFlag = true;
    

    OR

    if (!myFlag) myFlag = true;
    

    I would normally choose the former because it requires writing less code. However, I began to wonder that maybe it involved needless writing to memory and therefore the latter would prevent needless writing if myFlag was already true. But, would using the latter take more time because there is a conditional statement and therefore compile code using more instructions?

    Or maybe I am over-thinking this too much...


    UPDATE 1

    Just to clarify a bit...the purpose of my latter case is to not write to memory if the variable was already true. Thus, only write to memory if the variable is false.

  • Jack Aidley
    Jack Aidley about 11 years
    If the bool is in memory, the read/write of memory is likely to be the bottleneck not the CPU.
  • Jack Aidley
    Jack Aidley about 11 years
    It is possible to have the CPU stall on write but not on read. It's just not very likely.
  • Qortex
    Qortex about 11 years
    ok, but anyway you'll have to get it from memory to evaluate the if, and then it will most likely stay in cache memory. So access to memory is needed in both cases unless it's already in cache.
  • Jerry Coffin
    Jerry Coffin about 11 years
    @JackAidley: Oh, yeah, at least in theory (e.g., if you have only write-through caching). The circumstances to lead to writing being slower are beyond "not very likely", somewhere on the edge between "extremely rare" and "purely theoretical" though.