Use "greater than or equals" or just "greater than"

Question

I remember from C days that we were encouraged to use

i > -1

instead of

i >= 0

because of performance.

Does this still apply in the C# .NET world? What are the performance implications of using one over the other with today's compilers? i.e. Is the compiler clever enough to optimize these for you?

(As an aside try and type the question "use >= or >" into the question field on Stack Overflow and see what happens.)

Answer 1

No you don't need to do this any more. Yes the compilers have become much smarter and the two expressions have no performance differences.

Answer 2

No, there are no performance issues associated with comparison operators. And any good compiler would optimize something this trivial anyway.

I'm not sure where you got the suggestion to use "i > -1" rather than "i >= 0". On the x86 architecture, it makes no difference which you use: either case takes exactly two instructions... one to compare and one to jump:

 ;; if (i > -1) {
 cmp eax, -1
 jle else
then:
 ...
else:

 ;; if (i >= 0) {
 cmp eax, 0
 jl else
then:
 ...
else:

On most RISC architectures that I know, "i >= 0" may actually be faster since there is usually a dedicated zero register, and "i > -1" may require loading a constant. For example, MIPS only has a < instruction (no <=). Here is how the two constructs would be (naively!) expressed in MIPS assembly language:

 // if (i >= 0) {   (assuming i is in register %t0)

 stl $t1, $0, $t0     // in C: t1 = (0 < t0)
 beq $t1, $0, else    // jump if t1 == 0, that is if t0 >= 0
 nop
then:
 ...
else:

// if (i > -1) {    (assuming i is in register %t0)

 addi $t2, $0, -1      // in C: t2 = -1
 stl $t1, $t2, $t0      // in C: t1 = (t2 < t0) = (-1 < t0)
 bne $t1, $0, else     // jump if t1 != 0, that is if t0 > -1
 nop
then:
 ...
else:

So in the naive, general case, it will actually be one instruction faster to do "i >= 0" on MIPS. Of course, RISC code is so heavily optimizable that a compiler would likely change either of these instruction sequences almost beyond recognition :-)

So... the short answer is no no no, no difference.

Answer 3

I remember from C days that we were encouraged to use .... because of performance.

Are you sure about that? I've worked with computers going back to the early '70's (yes, at my father's knee...), and I've never seen a CPU that couldn't process >= just as fast as >. (BH "Branch High" vs. BNL "Branch Not Low" in IBM360 talk).

Answer 4

There is a very similar question (no criticism implied - as you say, searching for symbols is tricky) here: "Should one use < or <= in a for loop"

(Yes, I happen to be able to find it easily as I've got a lot of upvotes on my answer...)

Basically, do whatever's most readable. The day someone correctly guesses that making a change away from the most readable form is going to solve a performance problem (without the help of a profiler) is the day I stop talking about performance :)

Answer 5

Quite apart from the fact that any decent compiler does the right thing, and apart from that fact that in modern architectures there's no speed difference between > and >= comparisons, the bigger picture says that this is a "micro-optimisation" that doesn't affect runtime performance in the vast majority of cases.

In the case of comparisons it usually doesn't affect readability whichever way you write it, but there are occasions when picking one boundary over the other is clearer: e.g.,

if (length >= str.size())

versus

if (length > str.size() - 1)

I don't know about you, but I'd pick option 1 any day. :-) In cases that don't appreciably affect performance, such as this, the more readable option should win.

Answer 6

That might have been true for some shady scripting languages that break down a >= into 2 comparisons, but whoever encouraged you to use that for C... well... you should probably try hard to forget everything they ever told you.

Answer 7

This reminds me of the recommendation to use ++i instead of i++ (pre-increment vs. post-increment) because it was supposedly one instruction faster. (I forget where I originally read about this, but it was probably C/C++ Users' Journal or Dr. Dobb's Journal but I can't seem to find a web reference.)

I seriously doubt that > or >= is faster or slower; instead write your code for clarity.

As a side note, I developed a preference for the pre-increment (++i) operator even if the reason is now potentially outdated.