[SciPy-Dev] default scipy fft performance
Paul Anton Letnes
Fri Dec 21 11:30:54 CST 2012
On 21. des. 2012, at 16:53, David Cournapeau wrote:
> On Fri, Dec 21, 2012 at 3:16 PM, Paul Anton Letnes
> <firstname.lastname@example.org> wrote:
>> Dear Scipy devs,
>> 1) thanks for doing a great job in general!
>> 2) Why is there a huge performance difference between scipy.fft and scipy.fftpack.fft? It apperars that scipy.fft == numpy.fft:
>> In : import numpy as np
>> In : from scipy import fft
>> In : from scipy import fftpack
>> In : d = np.linspace(0, 1e3, 1e7)
>> In : %timeit np.fft.fft(d)
>> 1 loops, best of 3: 1.29 s per loop
>> In : %timeit fft(d)
>> 1 loops, best of 3: 1.3 s per loop
>> In : %timeit fftpack.fft(d)
>> 1 loops, best of 3: 651 ms per loop
>> 3) On a related note - what's the best performing python fft library/wrapper out there? I take it from some google research I did that e.g. fftw cannot be used due to the GPL licence.
> But you could use e.g. pyfftw that will give you a better wrapper that
> scipy ever had for FFTW.
> The difference in speed is not unexpected: the fft in numpy is there
> for historical reasons and backward compatibility. Unless you have a
> very good reason not to use it, you should be using scipy.fftpack
> instead of numpy.fft when you can depend on scipy.
I understand that this must be something like a backwards compatibility thing. But my point was (although I was perhaps not all that clear): Why does scipy.fft link to numpy.fft, and not scipy.fftpack.fft? The interface seems similar enough:
fft(a[, n, axis])
fft(x[, n, axis, overwrite_x])
The extra overwrite_x in fftpack shouldn't be much of an issue.
More information about the SciPy-Dev