Prev: multi-threaded FFTW segmentation fault with gfortran
Next: Initialization of character array in derived type
From: linuxl4 on 28 Dec 2007 08:50

> The program accumulates the unavoidable small errors
> over a large number of steps. So, Michel is probably
> quite right.

I understund. this program accumulates the unavoidable small errors
over a large number of steps.

thank you.
From: Arjen Markus on 28 Dec 2007 08:51
On 28 dec, 14:45, linu...(a)sohu.com wrote:
> This is just a test program to compare gfortran and ifort's speeds of
> calculating sin,cos and so on.since ifort calculates those functions
> with its simd intrinsics instead of libm, it is faster than gfortran.
> But a interesting thing I found is that gfortran can  also call
> ifort's libimf.so library to caculate sin/cos/tan function and the
> result is correct.

Okay, your purpose is clear. But keep in mind that the
differences may be due to rounding errors in the finite-precision
computations, rather than actual errors in the underlying
libraries.

You may still want to see how the differences evolve.

Regards,

Arjen
From: Michel Olagnon on 28 Dec 2007 09:02
linuxl4(a)sohu.com wrote:
> This is just a test program to compare gfortran and ifort's speeds of
> calculating sin,cos and so on.since ifort calculates those functions
> with its simd intrinsics instead of libm, it is faster than gfortran.
> But a interesting thing I found is that gfortran can also call
> ifort's libimf.so library to caculate sin/cos/tan function and the
> result is correct.

In that case, you should also be careful that you might not have
as many argument reductions to [0,2pi] in actual applications as
you have here, and that the speed ratio might then change...

From: linuxl4 on 28 Dec 2007 09:25

>
> Okay, your purpose is clear. But keep in mind that the
> differences may be due to rounding errors in the finite-precision
> computations, rather than actual errors in the underlying
> libraries.
>
> You may still want to see how the differences evolve.

since my purpose is to compare the speeds, I have to use the
optimization flags such as -O3 and so on. just like the above result
showes, these optimizations will also bring rounding errors . maybe
nothing I can do to avoid a wrong result.

From: linuxl4 on 28 Dec 2007 09:31

>
> In that case, you should also be careful that you might not have
> as many argument reductions to [0,2pi] in actual applications as
> you have here, and that the speed ratio might then change...

yes ,you are right. this can explain the result of another program.

x=0.0;N=3000000
do i=1,N
x=x+sin(dble(i))
enddo
print *,x
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: multi-threaded FFTW segmentation fault with gfortran
Next: Initialization of character array in derived type