The output for the
multi-dimensional rfftw is a more-conventional array of
fftw_complex values, but the format here permitted us greater
efficiency in one dimension.
The basic problem is the resolution of the clock: FFTW needs to run for a certain time for the clock to be reliable.
fftwnd actually may use some temporary
storage (hidden in the plan), but this storage space is only the size of
the largest dimension of the array, rather than being as big as the
entire array. (Unless you use fftwnd to perform one-dimensional
transforms, in which case the temporary storage required for in-place
transforms is as big as the entire array.)
The etymologically-correct spelling would be
frftw_, but it is hard to remember.
There is one exception: when performing
one-dimensional in-place transforms, the out parameter is always
ignored by the multi-threaded routines, instead of being used as a
workspace if it is non-NULL as in the uniprocessor routines. The
multi-threaded routines always allocate their own workspace (the size of
which depends upon the number of threads).
The 1D
transforms require much more communication. All the communication in
our FFT routines takes the form of an all-to-all communication: the
multi-dimensional transforms require two all-to-all communications (or
one, if you use FFTW_TRANSPOSED_ORDER), while the one-dimensional
transforms require three (or two, if you use scrambled input or
output).
An FFT is particularly hard on communications systems, as it requires an all-to-all communication, which is more or less the worst possible case.
Technically, Fortran 77 identifiers are not allowed to have more than 6 characters, nor may they contain underscores. Any compiler that enforces this limitation doesn't deserve to link to FFTW.
Each version of cc
seems to have its own magic incantation to get the fastest code most of
the time--you'd think that people would have agreed upon some
convention, e.g. "-Omax", by now.
This document was generated on 26 November 2003 using the texi2html translator version 1.52. (properly hacked by athena@theory.lcs.mit.edu)