How C# or any other language NOT Equal to operator performs

Question

Hi which one is faster

            int a = 100;
        //First Way
        if (a != 100)
        {
            //Do something when a is not equal to 100
        }
        else
        {
            //Do something when a is equal to 100
        }

        //Second Way
        if (a == 100)
        {
            //Do something when a is equal to 100

        }
        else
        {
            //Do something when a is not equal to 100
        }

I thinks second way is faster , but I am curious to Know how NOT EQUAL (!=) operator is solved . Is it like first it implements equal(==) operation and then the result is negated like !(a==100) ? Any help will be highly appericiated.

score 10 · Accepted Answer · edited May 23 '17 at 12:21

10

There is no difference between the two whatsoever. For an int, it all boils down to one of two assembly instructions on x86:

je - Jump if equal
jne - Jump it not equal

These, or any of the jxx instructions all take the same amount of time.

See also my other answer related to your question.

Since you really seem to care, I suggest you test it yourself. Write up two loops, one that uses == and one that uses !=. Then time them with a System.Diagnostics.Stopwatch, by wrapping them in calls to Start() and Stop(). Then compare. With a high enough number of iterations through the loop (to minimize other timing errors like context switches, interrupts, etc.) you will see no difference.

edited May 23 '17 at 12:21

Community

1
1

answered Jul 26 '12 at 04:26

Jonathon Reinhart

132,704
33
254
328

thats fine, but how this if equal and if not equal is determined. – yo chauhan Jul 26 '12 at 04:31
1

I don't know what more you want to know. The CPU compares values in two registers, typically with a `test` or `cmp` instruction, which sets the FLAGS. Then the `je` or `jne` instructions jump to the location in code that corresponds to the body of your `if` statement. – Jonathon Reinhart Jul 26 '12 at 04:35
If this isn't good enough, then I'm sorry, but you need a more low-level understanding of how computers work. – Jonathon Reinhart Jul 26 '12 at 04:36
See also: http://stackoverflow.com/questions/12135518/is-faster-than/12135533#12135533 – Jonathon Reinhart Aug 12 '13 at 15:04

score 1 · Answer 2 · answered Jul 26 '12 at 04:26

1

I think on the binary level, it's a single operation (don't quote me), so either is pretty much the same.

That said, if you're trying to optimize at this level, you're doing something wrong. This isn't assembly.

answered Jul 26 '12 at 04:26

darkphoenix

2,147
3
13
14

score -2 · Answer 3 · answered Jul 26 '12 at 04:32

-2

In my opinion, generally, the NOT EQUAL operation (!=) should be faster than EQUAL (==), as the NOT EQUAL operation will return result as soon as there's some chunk value (it based on your OS is 32-bit or 64-bit or so on) is not equal.

In your case, 2 operations should be faster equal, as 100 is an 4-byte integer.

And I think the 2 operator does not have the same implementation.

answered Jul 26 '12 at 04:32

Thinhbk

2,194
1
23
34

1

This is not correct at all. What does "some chunk value" mean? The OP is referring to `int` here. – Jonathon Reinhart Jul 26 '12 at 04:34
What he means is he *thinks* that not equal will "return" before an equal would because it encounters a mismatch quicker than checking the entire value for equality would. However, at bit-level, that's not quite how it works. Even if it did, you would be talking minuscule CPU cycles here. – Simon Whitehead Jul 26 '12 at 04:44
I mean: chunk value here is 4-byte (32 bit OS) or 8-byte (64 bit OS) CPU operation at bit level. As the question is about int32 (100), 2 operation should be the same, but if it's about int64 (100L), they may be different – Thinhbk Jul 26 '12 at 04:53

How C# or any other language NOT Equal to operator performs

3 Answers3