which one is faster/better > or >=

[Lasse Vågsæther Karlsen]

My guess is it would be slower by a small amount but you never know. Maybe
on some processor a < is faster than =. The only way to know is try it.

Michael

But it could be possible that the entire pixel comparison code could be
removed and replaced with altogether different constructs.

However, if you have already picked the algorithm that is the fastest
one, code-level optimizations like the OP's code would make sense.

But it should never be the first thing to try.

 

[Michael C]

This type of hairsplitting won't benefit you in any way you'll ever
notice. From a performance perspective, it's a complete waste of time even
thinking about it.

One thing I wanted to add was that if creating a fast algorithm then
something like this would just be one tool in the toolchest. It might gain a
1% advantage but in combination with other optimisations it could give real
benefits.

Michael

 

[Ian Semmel]

One thing I wanted to add was that if creating a fast algorithm then
something like this would just be one tool in the toolchest. It might
gain a
1% advantage but in combination with other optimisations it could give
real
benefits.

Michael

1% ??? It must be the most trivial algorithm of all time.
or
You meant .00001%

 

[Michael C]

1% ??? It must be the most trivial algorithm of all time.
or
You meant .00001%

Not necessarily. It just needs to be in a loop that doesn't have a lot of
code in that particular loop. There could be loops within loops within
loops. The inner most loop might be very trivial but that does not mean the
algorithm is. The other thing is the loop might well be extremely trivial,
such as flipping some bits in a bitmap.

Michael