[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] rint() vs. nearbyint()
From: |
Greg Chicares |
Subject: |
[lmi] rint() vs. nearbyint() |
Date: |
Wed, 3 Feb 2021 00:02:28 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
[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.
- [lmi] rint() vs. nearbyint(),
Greg Chicares <=