Calculating cosinus/sinus

Tim Prince n8tm@aol.com
Sat May 11 15:35:00 GMT 2013


On 05/11/2013 11:25 AM, Robert Dewar wrote:
> On 5/11/2013 11:20 AM, jacob navia wrote:
>
>> OK I did a similar thing. I just compiled sin(argc) in main.
>> The results prove that you were right. The single fsin instruction
>> takes longer than several HUNDRED instructions (calls, jumps
>> table lookup what have you)
>>
>> Gone are the times when an fsin would take 30 cycles or so.
>> Intel has destroyed the FPU.
>
> That's an unwarrented claim, but indeed the algorithm used
> within the FPU is inferior to the one in the library. Not
> so surprising, the one in the chip is old, and we have made
> good advances in learning how to calculate things accurately.
> Also, the library is using the fast new 64-bit arithmetic.
> So none of this is (or should be surprising).
>
>> In the benchmark code all that code/data is in the L1 cache.
>> In real life code you use the sin routine sometimes, and
>> the probability of it not being in the L1 cache is much higher,
>> I would say almost one if you do not do sin/cos VERY often.
>
> But of course you don't really care about performance so much
> unless you *are* using it very often. I would be surprised if
> there are any real programs in which using the FPU instruction
> is faster.
Possible, if long double precision is needed, within the range where 
fsin can deliver it.
I take it the use of vector sin library is excluded (not available for 
long double).
>
> And as noted earlier in the thread, the library algorithm is
> more accurate than the Intel algorithm, which is also not at
> all surprising.
reduction for range well outside basic 4 quadrants should be better in 
the library (note that fsin gives up for |x| > 2^64) but a double 
library function can hardly be claimed to be generally more accurate 
than long double built-in.
>>
>> For the time being I will go on generating the fsin code.
>> I will try to optimize Moshier's SIN function later on.
>
> Well I will be surprised if you can find significant
> optimizations to that very clever routine. Certainly
> you have to be a floating-point expert to even touch it!
>
> Robert Dewar
>
>


-- 
Tim Prince



More information about the Gcc mailing list