With today s CPUs (excluding maybe embedded machines and the Atom) you can t really make predictions on how fast a single inctruction in code may be.

First of all, it may be removed by the compiler if it s known to be irrelevant, it may be rewritten by the compiler into something different which is known to be faster, etc. That s one pitfall.

Secondly, CPUs can execute more than one instruction per cycle, or make them asynchronously and do other things while waiting for the FPU, etc.

In your specific case, comparing two numbers should be instant, i. e. in one cycle. But you probably can t use that result in that very same cycle already. But this should hold true for both integers and floating-point numbers.

Remember that it s just a series of bits and while floating-point numbers may be a little different due to their structure, it s still a pretty easy problem (compare sign, compare exponent, compare mantissa).

IIRC, standard IEEE 754 floating point numbers are stored in such a way that if you treat them as integers, they compare the same way:

| sign | exponent | significand |

The significand (a word I had completely forgotten before consulting the Wikipedia article) is the first few significant digits of the number.

If two floating point numbers a < b, then you have one of:

• a negative, b not negative;
• both same sign, but a s exponent < b s exponent; or
• both same sign and exponent, but a < b.

So you can simply take the 32 bits of each number as integers, and compare them using normal integer arithmetic. I do not know if this is what compilers do in practice. There are a few special representations for certain numbers and these edge cases may mean the FP processor has to do it differently.

See http://en.wikipedia.org/wiki/Floating_point#Internal_representation

processing a float even if treated as integer will take more because a float is bigger, on php i tested once just dividing 1 for 3 to 32.000.000 decimal digits and i took about 0.33 seconds, dividing 1 for 3 to 10 decimal digits took 0.0002 or something like that (these values may be a little off but depending on the size of the float it can take you a lot and to work with such big floats will take a hell of a lot of time, if you want to be more specific and test this subject it would be ideal because part of the time i waited could be because of memory speed or something like that, and not cpu)

anyway considering that you won t be crazy enough to work with floats with more that 50 decimal places you should be fine