6

Is it computationally more performant to compare less/greater than over less/greater than or equal to?

Intuitively one could think that less/greater than is marginally better.

Can a compiler use some trick to make the comparisons seem the same?

A compiler could eliminate e.g. less than or equal to with less than by incrementing the bound by one but if the bound is "alive" then this cannot be done.

heikkim
  • 2,955
  • 2
  • 24
  • 34
  • 1
    closely related: [Is < faster than <=?](http://stackoverflow.com/questions/12135518/is-faster-than) – davidhigh Nov 19 '14 at 12:29
  • 1
    It depends on the target architecture, so I don't think this question can be answered in general. – harold Nov 19 '14 at 12:30

1 Answers1

7

On virtually every modern CPU, there are compare/jumpless and compare/jumplessequal instructions that take exactly the same amount of time, because it runs through exactly the same hardware modulo including or not the "equals" bit.

It is the case that computing the "not less than" (and therefoe "less than") is sort of free; for unsigned values, it is equivalent to carry from a twos's complement subtraction, which the CPUs already do. Computing equal is harder: the CPU has to determine that all bits of the result of the subtraction are zero; for 64 bits CPUs, that's naively a 64 bit and-gate which is pretty big and thus slow. The CPU designers know this, and build very fast networks to detect this quickly, precisely so it isn't a bottleneck.

So the answer is "NO", or to be clear, they take the same amount of time, and there are no compiler tricks to change that.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341