![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
On Mon, May 12, 2008 at 8:26 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Pearu Peterson wrote:
djbfft is important for applications that need only the 2^n sizes support and here djbfft have speed advantage over other fft implementations. For some of these applications the fft speed can be crusial.
Are you sure djbfft speed advantage is still true today ? When I run scipy.fftpack.bench, I hardly see any different between fftw3 and djbfft, and the current use of fftw3 is less than optimal (we can at least get a two fold increase with an improved design, because right now, we are using the worst possible plan method).
When I run the benchmarks, the only backend significantly faster than the other ones is the MKL.
Neither djbfft vs. fftw nor djbfft vs. MKL are definitive comparisons. Not everyone can use GPLed code or proprietary code. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco