Chris@10: Chris@10: Chris@10: 64-bit Guru Interface - FFTW 3.3.3 Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10: Chris@10:
Chris@10: Chris@10: Chris@10:

Chris@10: Previous: Guru Real-to-real Transforms, Chris@10: Up: Guru Interface Chris@10:


Chris@10:
Chris@10: Chris@10:

4.5.6 64-bit Guru Interface

Chris@10: Chris@10:

Chris@10: When compiled in 64-bit mode on a 64-bit architecture (where addresses Chris@10: are 64 bits wide), FFTW uses 64-bit quantities internally for all Chris@10: transform sizes, strides, and so on—you don't have to do anything Chris@10: special to exploit this. However, in the ordinary FFTW interfaces, Chris@10: you specify the transform size by an int quantity, which is Chris@10: normally only 32 bits wide. This means that, even though FFTW is Chris@10: using 64-bit sizes internally, you cannot specify a single transform Chris@10: dimension larger than Chris@10: 231−1numbers. Chris@10: Chris@10:

We expect that few users will require transforms larger than this, but, Chris@10: for those who do, we provide a 64-bit version of the guru interface in Chris@10: which all sizes are specified as integers of type ptrdiff_t Chris@10: instead of int. (ptrdiff_t is a signed integer type Chris@10: defined by the C standard to be wide enough to represent address Chris@10: differences, and thus must be at least 64 bits wide on a 64-bit Chris@10: machine.) We stress that there is no performance advantage to Chris@10: using this interface—the same internal FFTW code is employed Chris@10: regardless—and it is only necessary if you want to specify very Chris@10: large transform sizes. Chris@10: Chris@10: Chris@10:

In particular, the 64-bit guru interface is a set of planner routines Chris@10: that are exactly the same as the guru planner routines, except that Chris@10: they are named with ‘guru64’ instead of ‘guru’ and they take Chris@10: arguments of type fftw_iodim64 instead of fftw_iodim. Chris@10: For example, instead of fftw_plan_guru_dft, we have Chris@10: fftw_plan_guru64_dft. Chris@10: Chris@10:

     fftw_plan fftw_plan_guru64_dft(
Chris@10:           int rank, const fftw_iodim64 *dims,
Chris@10:           int howmany_rank, const fftw_iodim64 *howmany_dims,
Chris@10:           fftw_complex *in, fftw_complex *out,
Chris@10:           int sign, unsigned flags);
Chris@10: 
Chris@10:

Chris@10: The fftw_iodim64 type is similar to fftw_iodim, with the Chris@10: same interpretation, except that it uses type ptrdiff_t instead Chris@10: of type int. Chris@10: Chris@10:

     typedef struct {
Chris@10:           ptrdiff_t n;
Chris@10:           ptrdiff_t is;
Chris@10:           ptrdiff_t os;
Chris@10:      } fftw_iodim64;
Chris@10: 
Chris@10:

Chris@10: Every other ‘fftw_plan_guru’ function also has a Chris@10: ‘fftw_plan_guru64’ equivalent, but we do not repeat their Chris@10: documentation here since they are identical to the 32-bit versions Chris@10: except as noted above. Chris@10: Chris@10: Chris@10: Chris@10: