简体   繁体   中英

Use “greater than or equals” or just “greater than”

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? ie 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.)

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.

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: eg,

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.

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 :)

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.

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).

对于某些将> =分解为2个比较的阴暗脚本语言而言,这可能是正确的,但是无论谁鼓励您将其用于C ...好吧...您可能应该努力忘记他们曾经告诉过您的所有内容。

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.

For greater than zero, it must make two checks. It checks if the negative bit is off and it checks if the zero bit is off.

For greater than or equal to zero, it only has to check if the negative bit is off, because we don't care if the zero bit is on or off.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM