CODEWITHSUNDEEP
c++cif-statement
jsist
jsist

Reputation: 5253

What is efficient to check: equal to or not equal to?

I was wondering, if we have if-else condition, then what is computationally more efficient to check: using the equal to operator or the not equal to operator? Is there any difference at all?

E.g., which one of the following is computationally efficient, both cases below will do same thing, but which one is better (if there's any difference)?

Case1:

if (a == x)
{
    // execute Set1 of statements
}
else
{
    // execute Set2 of statements
}

Case 2:

if (a != x)
{
    // execute Set2 of statements
}
else
{
    // execute Set1 of statements
}

Here assumptions are most of the time (say 90% of the cases) a will be equal to x. a and x both are of unsigned integer type.

Upvotes: 7

Views: 4283

Answers (14)

Marko Topolnik
Marko Topolnik

Reputation: 200168

If you ever manage to write a piece of Java code that can be proven to be significantly more efficient one way than the other, you should publish your result and raise an issue against whatever implementation you observed the difference on.

More to the point, just asking this kind of question should be a sign of something amiss: it is an indication that you are focusing your attention and efforts on a wrong aspect of your code. Real-life application performance always suffers from inadequate architecture; never from concerns such as this.

Upvotes: 4

Parvin Gasimzade
Parvin Gasimzade

Reputation: 26012

Performance difference between them is negligible. So, just think about readability of the code. For readability I prefer the one which has a more lines of code in the If statement.

if (a == x) { 
    // x lines of code
} else {
    // y lines of code where y < x
}

Upvotes: 0

Eric Postpischil
Eric Postpischil

Reputation: 222826

GCC provides a way to inform the compiler about the likely outcome of an expression:

if (__builtin_expect(expression, 1))
…

This built-in evaluates to the value of expression, but it informs the compiler that the likely result is 1 (true for Booleans). To use this, you should write expression as clearly as possible (for humans), then set the second parameter to whichever value is most likely to be the result.

Upvotes: 5

Peter Lawrey
Peter Lawrey

Reputation: 533530

Usually what you should consider is; what is the simplest and clearest way to write this code? IMHO, the first, positive is the simplest (not requiring a !)

In terms of performance there is no differences as the code is likely to compile to the same thing. (Certainly in the JIT for Java it should)

For Java, the JIT can optimise the code so the most common branch is preferred by the branch prediction.

Upvotes: 10

John Bode
John Bode

Reputation: 123468

The only way to know for sure is to code up both versions and measure their performance. If the difference is only a percent or so, use the version that more clearly conveys the intent.

It's very unlikely that you're going to see a significant difference between the two.

Upvotes: 0

muthukumar
muthukumar

Reputation: 2243

Only the non-negative approach which you have used at the first seems to be the best .

Upvotes: 0

Kevin
Kevin

Reputation: 2730

Most processors use an electrical gate for equality/inequality checks, this means all bits are checked at once. Therefore it should make no difference, but you want to truly optimise your code it is always better to benchmark things yourself and check the results.
If you are wondering whether it's worth it to optimise like that, imagine you would have this check multiple times for every pixel in your screen, or scenarios like that. Imho, it is alwasy worth it to optimise, even if it's only to teach yourself good habits ;)

Upvotes: 0

Big J. Lee
Big J. Lee

Reputation: 53

Let the compiler/optimizer do its work. It's a general rule of thumb (most nowadays) that the source code should express your intention in the most readable way. You are writing it to another human (and not to the computer), the one year later yourself or your team mate who will need to understand your code with the less effort.

Upvotes: 2

Duane
Duane

Reputation: 1990

It shouldn't make any difference performance wise but you consider what is easiest to read. Then when you are looking back on your code or if someone is looking at it, you want it to be easy to understand.

Upvotes: 1

sleepsort
sleepsort

Reputation: 1331

Early optimization is the root of all evil

Even for branch prediction, I think you should not care too much about this, until it is really necessary.

Just as Peter said, use the simplest way.

Upvotes: 2

Philipp
Philipp

Reputation: 69663

There is no difference.

The x86 CPU architecture has two opcodes for conditional jumps

JNE (jump if not equal)
JE (jump if equal)

Usually they both take the same number of CPU cycles.

And even when they wouldn't, you could expect the compiler to do such trivial optimizations for you. Write what's most readable and what makes your intention more clear instead of worrying about microseconds.

Upvotes: 4

AlexWien
AlexWien

Reputation: 28727

it has a little advantage (from point of readability) if the first condition is the one that is true in most cases. Write the conditions that way that you can read them best. You will not benefit from speed by negating a condition

Upvotes: 0

Luchian Grigore
Luchian Grigore

Reputation: 258618

In this simple case, it makes no difference. (assuming a and x are basic types) If they're class-types with overloaded operator == or operator != they might be different, but I wouldn't worry about it.

For subsequent loops:

if ( c1 )   { }
else if ( c2 ) { }
else ...

the most likely condition should be put first, to prevent useless evaluations of the others. (again, not applicable here since you only have one else).

Upvotes: 8

Crog
Crog

Reputation: 1170

Generally it shouldn't matter for performance which operator you use. However it is recommended for branching that the most likely outcome of the if-statement comes first.

Upvotes: 10

Related Questions