>>> There might still be some slowdown for certain inputs since glibc’s
>>> software routines are used instead of the inaccurate sin x87 instruction
>>> - just less dramatic as the numbers above show. But you’ll get better
>>> precision
>>
>> You mean that some of the hardware cpu math instructions are
>> inaccurate,
>> and thus we have to use again software implementations, as we did 20
>> years ago before the math coprocesor was invented? That’s a shame
>
> Yes, exactly. The Intel manual explains these limitations on sine and
> cosine.
I understood that the entire sine and cosine functions in libm are
implemented in software, not using at all the sin/cos hardware
instructions of the “coprocesor” (which is no longer a separate unit
since many years).
A friend of mine argues that is impossible, that he understand that for
certain input values are calculated in hardware and certain others are
in software.
Can somebody clarify this point, please?
There is a mention of a manual, but I don’t know which. Link, perhaps?
We’d be also interested in knowing to what extent does libm use the
coprocesor functions (I don’t really know how to call them).
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2013-12-18, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
> I understood that the entire sine and cosine functions in libm are
> implemented in software, not using at all the sin/cos hardware
> instructions of the “coprocesor” (which is no longer a separate unit
> since many years).
>
> A friend of mine argues that is impossible,
Of course your friend is incorrect. There are many different ways to calculate sines and cosines using software e.g. see http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD – which uses the inefficient
Taylor seres method. I’d assume the software implementation in libm uses the gold standard Payne and Hanek method.
> that he understand that for
> certain input values are calculated in hardware and certain others are
> in software.
Implementing comparator operations to test for certain input values seems both arbitrary and inefficient.
> Can somebody clarify this point, please?
I think you need to ask your friend to clarify his/her point e.g. what is the criteria that deems the input value
appropriate for hardware or software calculation? You should ask him/her for a reference. As far as I can see, libm is
all software-calculated unless you compile with certain flags (which don’t work for me anyway).
> There is a mention of a manual, but I don’t know which. Link, perhaps?
I find official documentation of this kind of thing thin on the ground. If you Google Christoph Lauter and/or Joseph Myers,
you can usually find some discussion on the matter.
> We’d be also interested in knowing to what extent does libm use the
> coprocesor functions (I don’t really know how to call them).
To my knowledge, the only way to call floating point unit instructions directly (rather than for example using SSE2
intrinsics) is using assembler or inline assembler.