![](https://secure.gravatar.com/avatar/9820b5956634e5bbad7f4ed91a232822.jpg?s=120&d=mm&r=g)
12 May
2008
12 May
'08
9:26 p.m.
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. cheers, David