views:

180

answers:

3

What is generally faster:

if (num >= 10)

or:

if (!(num < 10))
+10  A: 

Any decent compiler will optimize those two statements to exactly the same underlying code. In fact, it will most likely generate exactly the same code for:

if (!(!(!(!(!(!(!(num < 10))))))))

I would opt for the first of yours just because its intent seems much clearer (mildly clearer than your second choice, massively clearer than that monstrosity I posted above). I tend to think in terms of how I would read it. Think of the two sentences:

  • if number is greater than or equal to ten.
  • if it's not the case that number is less than ten.

I believe the first one to be clearer.

In fact, just testing with "gcc -s" to get the assembler output, both statements generate the following code:

cmpl $9,-8(%ebp) ; compare value with 9
jle .L3          ; branch if 9 or less.

I believe you're wasting your time looking at micro-optimisations like this - you'd be far more efficient looking at things like algorithm selection. There's likely to be a much greater return on investment there.

paxdiablo
+24  A: 

The compiler will most likely optimize that sort of thing. Don't worry about it, just code for clarity in this case. If you really do care, try profiling it ;)

Late edit: As an aside, assembly languages often have operations for >= and <= that are the same number of steps as < and >. For instance, with a Motorola 68k, if you want to compare the data registers %d0 and %d1 and branch if %d0 is greater than or equal to %d1, you would say something like:

cmp %d0, %d1  // compare %d0 and %d1, storing the result
              // in the condition code registers.
bge labelname // Branch to the given label name if the comparison
              // yielded "greater than or equal to" (hence bge)

It's a common mistake to think that a >= b means the computer will perform two operations instead of one because of that "or" in "greater than or equal to".

Joey Adams
If the optimizer does not optimize it, get a better compiler!
Jonathan Leffler
+2  A: 

In general any speed difference won't matter a great deal, but they don't necessarily mean exactly the same thing.

In many languages, comparing the floating point value NaN returns false for all comparisons, so if num = NaN, the first is false and the second true.

#include <iostream>
#include <limits>

int main ( ) {
    using namespace std;

    double num = numeric_limits<double>::quiet_NaN();

    cout << boolalpha;
    cout << "( num >= 10 )      " << ( num >= 10 ) << endl;
    cout << "( ! ( num < 10 ) ) " << ( ! ( num < 10 ) ) << endl;

    cout << endl;
}

outputs

( num >= 10 )      false
( ! ( num < 10 ) ) true

So the compiler can use a single instruction to compare num and the value 10 in the first case, but in the second may issue a second instruction to invert the result of the comparison. ( or it may just use a branch if zero rather than branch if non-zero, you can't say in general )

Other languages and compilers will vary, and for types where they really have the same semantics the code emitted might well be identical.

Pete Kirkham