FFTW on 64-bit platforms

[job]

I recently tried using fftw instead of the built-in fft libraries, and this caused some crashes on Linux/amd64. Turns out that the plan variables need to be big enough for a pointer. One could compile with some "-i8" switch, but the MPI libraries we use want 32-bit integers. So the following patch provides a solution to that problem:

Code: Select all

% diff fftw3d.F.orig fftw3d.F
90c90,92
<        integer grid(3), isign, plan
---
>        integer, parameter :: pk = selected_int_kind(18)
>        integer grid(3), isign
>        integer(pk) :: plan
118c120,122
<        integer grid(3),plan
---
>        integer, parameter :: pk = selected_int_kind(18)
>        integer grid(3)
>        integer(pk) :: plan

and for the mpi version:

Code: Select all

% diff fftmpiw.F.orig fftmpiw.F
56c56,58
<       INTEGER :: planx, plany, planz
---
>       ! Integer kind for plans should be large enough for a pointer.
>       integer, parameter :: pk = selected_int_kind(18)
>       INTEGER(pk) :: planx, plany, planz

[ericsun]

Hi,

This works for both AMD64 and EM64T.

But, I found a slow-down of performance (5-9%) after calling FFTW,
compared with jF's FFT. This is not the case on my P4 machines without
EM64T. Is this usual?

[job]

I found that compiling fftw 3 with gcc produced about 15 % faster results on the ffttest benchmark included with VASP than when using pathCC. You can still use another Fortran compiler by compiling the fftw Fortran interface with it (I use pathf90). My understanding is that this performance difference is because the sse2 optimizations in fftw are only enabled when compiling it with gcc.

Truth to be told, at least on our Opteron systems here, the difference between jF FFT and FFTW (compiled with gcc as mentioned above) is rather small when running actual calculations. For bench.Hg I measured a 2 % advantage for fftw (i.e. noise).

[ccfisch]

hi Job,

Thanks for the post ! It would have definitely taken me some time to track this one down (I had only isolated the seg faults to the use of fftw).

To add another perspective on the FFTW discussion, I'm building vasp with gfortran on an x86_64 arch and the difference between FFTW and jF FFT is quite substantial (I suppose due to gfortran). For example, timings of the EDDAV routine are reduced by a factor of 4 with multiple test runs.

[job]

It seems that the current vasp version (4.6.34) incorporates this fix. Although they have used the quick-and-dirty (potentially unportable) INTEGER(8) rather than selected_int_kind like my patch does.