[lmi] rint() vs. nearbyint()

[Greg Chicares]

[I answer my own question, but I found the answer interesting.]

Vadim--C99 (N1256, which is probably good enough for this purpose) says:

| F.9.6.4 The rint functions
| The rint functions differ from the nearbyint functions only in that they do 
raise the
| "inexact" floating-point exception if the result differs in value from the 
argument.

Does this mean anything in practice--i.e., do library implementations
really differ? If so, is rint() implemented in terms of nearbyint(),
or vice versa?

Here's why I ask. I really do want to call one of them with an infinite
argument. If either is faster, faster is preferable; and here I'm
interested in establishing a general principle, so I don't care if I'm
only saving a single machine cycle, as long as the savings is positive
or at least nonnegative.

My guess is that rint() is implemented as nearbyint() with added
guards that conditionally raise FE_INEXACT.

But wait--I can just check the glibc sources myself:

https://github.com/bminor/glibc/blob/be9b0b9a012780a403a266c90878efffb9a5f3ca/sysdeps/ieee754/dbl-64/s_rint.c
https://github.com/bminor/glibc/blob/be9b0b9a012780a403a266c90878efffb9a5f3ca/sysdeps/ieee754/dbl-64/s_nearbyint.c

and it looks like my guess was wrong: nearbyint() is implemented as
a copy of the rint() code, surrounded by additional code to save and
restore fenv_t. That makes sense: probably the silicon itself raises
FE_INEXACT, and suppressing it takes extra work (probably far more
than one machine cycle).

Of course, some other standard library may do differently, but this
is good enough for me: rint() is terser, and is likely to be faster.