Thread: Faster bitwise operator

Is != or < faster?
In the bignum class I made, != is faster. And just from what I can best think of, it would be for the processor register comparison too.
But I just wanted to confirm this with you guys - which is faster?

I would wager that both are done in constant time, and whether one is faster than the other depends on processing power.

Back to "Is != or < faster?" specifically, let me invoke a hint of history here.

This is the same in C or C++; they are elementary statements.

C was originally written to replace an assembler, essentially to be a chip independent assembler or just slightly higher than assembler.

Many constructs in the elementary syntax of C (and therefore C++) translate into 1 assembler instruction, when a chip supports that as such. These two happen to translate to x86 instructions of identical meaning (!= or <, >, >=, <=, etc).

As such, the speed of such comparisons, or of any of the elementary constructs like this, will relate closely to the chip on which you're executing. So, from a language viewpoint, it hardly makes sense to think of this in terms of the "language speed", but of the fact that implementations differ, optimizations may significantly affect some of the basic constructs and you generally shouldn't focus on microscopic performance issues too early. There are very rare exceptions to this general rule, and by the time you get to the point that it matters in your work, you'll have some sense of the assembler implications of your C/C++ code anyway, and the question will be moot.

I risk promoting unwanted pedantic continuation, but....

For some reason I kept thinking about this question as I tried to sleep.

To further illustrate why this particular subject of optimization does not make sense to pursue:

The speed of the comparison doesn't lie simply in the clock tick count of cmp and a conditional jump (the x86 assembler resulting from an integer comparison of any kind). The actual result - that is, whether the jump is taken or not, which is also saying whether the test is true or not, affects the speed.

If a jump is taken, we can't easily account for the cost of what happens to the instruction cache, the delay in RAM for selecting the jump destination instruction vs the 'next' instruction should the jump NOT be taken. This means the data feed into a loop that uses such a test could affect the performance.

If you changed the comparison, perhaps it might affect the predilection of the branch predictor to be correct more often than not, and, here's where it really suggests the futility of the idea - the previous instructions that were in the CPU's pipeline might affect the speed of the transition between cmp and the conditional jump.

Say there were a multiplication prior to the cmp, and assume that the results of the multiplication are not involved with the operands of the cmp (the instructions are not interdependent).

Depending on alignment relative to the availability of execution units that the moment the cmp is to be scheduled, the CPU might be performing the previous multiplication instruction at the same time - parallel execution like this is part of modern CPU operation.

However, the pending conditional jump may not execute until the multiplication is finished, which takes more clock cycles than a cmp. In essense, the cmp may be held up by the multiplication which preceded it, in the logical stream of instructions.

In other words, the surrounding environment of code would have impact on the performance of a particular fast instruction, like cmp is, relative to a question like this, and indeed, points us back to the observation that we're dealing with assembler level optimizations that must be CPU aware (since different CPU's have different characteristics along the lines of execution units, branch prediction robustness, cache sizes, it goes on....)

Wraithan and others point out, this can't be a position of bottleneck, and optimization of code for instructions that amount to 1 or 2 clock ticks is a focus in the wrong direction.

For any improvement one might hope to gain, you'd have much more significant results with an extra 100Mhz, a larger cache or a smarter branch predictor than any microscopic comparison at this level.

All of this suggests that any answer beyond the fact that the instructions have the same timing is no meaning. That is, if someone conducts a test, and as a result of comparing != to < and others, somehow sees data that suggests != is faster or slower, it can't be taken as a generalized result that applies to all uses of !=. In a different context, != might be slower, and those assuming the previous test of speed were valid would have been mislead.

Understood - thanks for the info.