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
