Which is more performant: <= 0 or <1?

Back in the day when I was learning C and assembly we were taught it is better to use simple comparisons to increase speed. So for example if you say:

if(x <= 0)

versus

if(x < 1)

which would execute faster? My argument (which may be wrong) is the second would almost always execute faster because there is only a single comparison) ie is it less than one, yes or no.

Whereas the first will execute fast if the number is less than 0 because this equates to true there is no need to check the equals making it as fast as the second, however, it will always be slower if the number is 0 or more because it has to then do a second comparison to see if it is equal to 0.

I am now using C# and while developing for desktops speed is not an issue (at least not to the degree that his point is worth arguing), I still think such arguments need to be considered as I am also developing for mobile devices which are much less powerful than desktops and speed does become an issue on such devices.

For further consideration, I am talking about whole numbers (no decimals) and numbers where there cannot be a negative number like -1 or -12,345 etc (unless there is an error), for example, when dealing with lists or arrays when you cant have a negative number of items but you want to check if a list is empty (or if there is a problem, set the value of x to negative to indicate error, an example is where there are some items in a list, but you cannot retrieve the whole list for some reason and to indicate this you set the number to negative which would not be the same as saying there are no items).

For the reason above I deliberately left out the obvious

if(x == 0)

and

if(x.isnullorempty())

and other such items for detecting a list with no items.

Again, for consideration, we are talking about the possibility of retrieving items from a database perhaps using SQL stored procedures which have the functionality mentioned (ie the standard (at least in this company) is to return a negative number to indicate a problem).

So in such cases, is it better to use the first or the second item above?


They're identical. Neither is faster than the other. They both ask precisely the same question, assuming x is an integer. C# is not assembly. You're asking the compiler to generate the best code to get the effect you are asking for. You aren't specifying how it gets that result.

See also this answer.

My argument (which may be wrong) is the second would almost always execute faster because there is only a single comparison) ie is it less than one, yes or no.

Clearly that's wrong. Watch what happens if you assume that's true:

< is faster than <= because it asks fewer questions. (Your argument.)

> is the same speed as <= because it asks the same question, just with an inverted answer.

Thus < is faster than > ! But this same argument shows > is faster than < .

"just with an inverted answer" seems to sneak in an additional boolean operation so I'm not sure I follow this answer.

That's wrong (for silicon, it is sometimes correct for software) for the same reason. Consider:

3 != 4 is more expensive to compute than 3 == 4 , because it's 3 != 4 with an inverted answer, an additional boolean operation.

3 == 4 is more expensive than 3 != 4 , because it's 3 != 4 with an inverted answer, an additional boolean operation.

Thus, 3 != 4 is more expensive than itself.

An inverted answer is just the opposite question, not an additional boolean operation. Or, to be a bit more precise, it's with a different mapping of comparison results to final answer. Both 3 == 4 and 3 != 4 require you to compare 3 and 4. That comparison results in ether "equal" or "unequal". The questions just map "equal" and "unequal" to "true" and "false" differently. Neither mapping is more expensive than the other.


At least in most cases, no, there's no advantage to one over the other.

A <= does not normally get implemented as two separate comparisons. On a typical (eg, x86) CPU, you'll have two separate flags, one to indicate equality, and one to indicate negative (which can also mean "less than"). Along with that, you'll have branches that depend on a combination of those flags, so < translates to a jl or jb (jump if less or jump if below --the former is for signed numbers, the latter for unsigned). A <= will translate to a jle or jbe (jump if less than or equal, jump if below or equal).

Different CPUs will use different names/mnemonics for the instructions, but most still have equivalent instructions. In every case of which I'm aware, all of those execute at the same speed.

Edit: Oops -- I meant to mention one possible exception to the general rule I mentioned above. Although it's not exactly from < vs. <= , if/when you can compare to 0 instead of any other number, you can sometimes gain a little (minuscule) advantage. For example, let's assume you had a variable you were going to count down until you reached some minimum. In a case like this, you might well gain a little advantage if you can count down to 0 instead of counting down to 1. The reason is fairly simple: the flags I mentioned previously are affected by most instructions. Let's assume you had something like:

   do {
       // whatever
   } while (--i >= 1);

A compiler might translate this to something like:

loop_top:
    ; whatever

    dec i
    cmp i, 1
    jge loop_top

If, instead, you compare to 0 ( while (--i > 0) or while (--i != 0) ), it might translate to something like this instead;

loop_top:
    ; whatever

    dec i
    jg loop_top
    ; or: jnz loop_top

Here the dec sets/clears the zero flag to indicate whether the result of the decrement was zero or not, so the condition can be based directly on the result from the dec , eliminating the cmp used in the other code.

I should add, however, that while this was quite effective, say, 30+ years ago, most modern compilers can handle translations like this without your help (though some compilers may not, especially for things like small embedded systems). IOW, if you care about optimization in general, it's barely possible that you might someday care -- but at least to me, application to C# seems doubtful at best.


Most modern hardware has built-in instructions for checking the less-than-or-equals consition in a single instruction that executes exactly as fast as the one checking the less-than condition. The argument that applied to the (much) older hardware no longer applies - choose the alternative that you think is most readable, ie the one that better conveys your idea to the readers of your code.

链接地址: http://www.djcxy.com/p/31566.html

上一篇: 哪个运算符更快(>或> =),(<或<=)?

下一篇: 哪一个更高性能:<= 0或<1?