In C, is testing if a float is NaN as fast as testing if two floats are equal? That is is isnan() as fast a simple equality test between two floats?
My particular interest is using gcc on a standard modern Intel/AMD platform.
Here is a sample piece of C code.
#include <math.h>
int main(double x)
{
return isnan(x);
}
Using GCC on x64, math.h's isnan(float) compiles to
jmp __isnanf
Using tail-call optimization, but effectively calling a function. The called function will have to do something equivalent to the code a bit down, at least I don't see any faster way to implement it. That leaves the question how it compares to a comparison unanswered however.
But that doesn't say anything about how fast "testing if a float is NaN" is, because there isn't just the one way to do it. The most direct way,
int isnan2(float x)
{
return x != x;
}
Is literally the same thing as comparing floats at the C level. But GCC makes this:
xor eax, eax
ucomiss xmm0, xmm0
setp al
ret
Which is not quite the same thing as comparing two floats, but close, and in fact a bit faster. Testing for equality means the unordered case tested, as it is here, but then the z flag also has to be tested, like this (from gcc again)
xor eax, eax
mov edx, 1
ucomiss xmm0, xmm1
setp al
cmovne eax, edx
ret
Bonus: using <cmath> makes isnan compile to the same thing as comparing a float to itself, see the linked question for why.
I now see you actually had double, but that doesn't change anything qualitatively.
The question is if we should use something other than NaN in our code to represent unknown values. (OP comment)
Then you should compare isnan(x) with x == some_constant. If that some_constant did not have a value of 0 or NAN, then the compare could simply be a bit compare if using typical FP representation - hard to beat that by much for speed.
Still, NaN is more idiomatic.
No. The equality test is inline so you pay the price of a function call overhead calling isnan(). But equality can't be used w/o IEEE, so ...
