Is < faster than <=?

Is `if (a < 901)` faster than `if (a <= 900)`?

Not exactly as in this simple example, but there are slight performance changes on loop complex code. I suppose this has to do something with generated machine code in case it's even true.

This would be highly dependent on the underlying architecture that the C is compiled to. Some processors and architectures might have explicit instructions for equal to, or less than and equal to, which execute in different numbers of cycles.

That would be pretty unusual though, as the compiler could work around it, making it irrelevant.

You should not be able to notice the difference even if there is any. Besides, in practice, you'll have to do an additional `a + 1` or `a - 1` to make the condition stand unless you're going to use some magic constants, which is a very bad practice by all means.

Assuming we're talking about internal integer types, there's no possible way one could be faster than the other. They're obviously semantically identical. They both ask the compiler to do precisely the same thing. Only a horribly broken compiler would generate inferior code for one of these.

If there was some platform where `<` was faster than `<=` for simple integer types, the compiler should *always* convert `<=` to `<` for constants. Any compiler that didn't would just be a bad compiler (for that platform).

Maybe the author of that unnamed book has read that `a > 0` runs faster than `a >= 1` and thinks that is true universally.

But it is because a `0` is involved (because `CMP` can, depending on the architecture, replaced e.g. with `OR`) and not because of the `<`.

For floating point code, the <= comparison may indeed be slower (by one instruction) even on modern architectures. Here's the first function:

int compare_strict(double a, double b) { return a < b; }

On PowerPC, first this performs a floating point comparison (which updates `cr`, the condition register), then moves the condition register to a GPR, shifts the "compared less than" bit into place, and then returns. It takes four instructions.

Now consider this function instead:

int compare_loose(double a, double b) { return a <= b; }

This requires the same work as `compare_strict` above, but now there's two bits of interest: "was less than" and "was equal to." This requires an extra instruction (`cror` - condition register bitwise OR) to combine these two bits into one. So `compare_loose` requires five instructions, while `compare_strict` requires four.

You might think that the compiler could optimize the second function like so:

int compare_loose(double a, double b) { return ! (a > b); }

However this will incorrectly handle NaNs. `NaN1 <= NaN2` and `NaN1 > NaN2` need to both evaluate to false.