cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: FFTW 3.3.8: 64-bit Guru Interface cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167:
cannam@167:

cannam@167: Previous: , Up: Guru Interface   [Contents][Index]

cannam@167:
cannam@167:
cannam@167: cannam@167:

4.5.6 64-bit Guru Interface

cannam@167: cannam@167: cannam@167:

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

cannam@167:

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

cannam@167: cannam@167:

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

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

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

cannam@167:
cannam@167:
typedef struct {
cannam@167:      ptrdiff_t n;
cannam@167:      ptrdiff_t is;
cannam@167:      ptrdiff_t os;
cannam@167: } fftw_iodim64;
cannam@167: 
cannam@167: cannam@167: cannam@167:

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

cannam@167:
cannam@167:
cannam@167:

cannam@167: Previous: , Up: Guru Interface   [Contents][Index]

cannam@167:
cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: