![](https://secure.gravatar.com/avatar/d98bd91ed2cea43056594b7ce5369b17.jpg?s=120&d=mm&r=g)
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 [4]: import numpy as np In [5]: from scipy import fft In [6]: from scipy import fftpack In [7]: d = np.linspace(0, 1e3, 1e7) In [8]: %timeit np.fft.fft(d) 1 loops, best of 3: 1.29 s per loop In [9]: %timeit fft(d) 1 loops, best of 3: 1.3 s per loop In [10]: %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. Cheers, Paul
![](https://secure.gravatar.com/avatar/59bdb3784070f0a6836aca9ee03ad817.jpg?s=120&d=mm&r=g)
On Fri, Dec 21, 2012 at 3:16 PM, Paul Anton Letnes <paul.anton.letnes@gmail.com> 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 [4]: import numpy as np
In [5]: from scipy import fft
In [6]: from scipy import fftpack
In [7]: d = np.linspace(0, 1e3, 1e7)
In [8]: %timeit np.fft.fft(d) 1 loops, best of 3: 1.29 s per loop
In [9]: %timeit fft(d) 1 loops, best of 3: 1.3 s per loop
In [10]: %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. regards, David
![](https://secure.gravatar.com/avatar/86ea939a72cee216b3c076b52f48f338.jpg?s=120&d=mm&r=g)
Den 21. des. 2012 kl. 16:53 skrev David Cournapeau <cournape@gmail.com>:
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.
Enthought is a good reason, as numpy.fft will use MKL. Another good reason is that the wrapper for numpy.fft is written in a way that makes it easy to release the GIL (no global states in C land), whereas scipy.fftpack is not reentrant. Sometimes it can be nice to do multiple FFTs in parallel threads. (I might try to re-post a PR to NumPy for releasing the GIL in numpy.fft again, unless it is taken care of now, but last time nobody cared to review it.) Sturla
![](https://secure.gravatar.com/avatar/d98bd91ed2cea43056594b7ce5369b17.jpg?s=120&d=mm&r=g)
On 21. des. 2012, at 16:53, David Cournapeau wrote:
On Fri, Dec 21, 2012 at 3:16 PM, Paul Anton Letnes <paul.anton.letnes@gmail.com> 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 [4]: import numpy as np
In [5]: from scipy import fft
In [6]: from scipy import fftpack
In [7]: d = np.linspace(0, 1e3, 1e7)
In [8]: %timeit np.fft.fft(d) 1 loops, best of 3: 1.29 s per loop
In [9]: %timeit fft(d) 1 loops, best of 3: 1.3 s per loop
In [10]: %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. Cheers Paul
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Fri, Dec 21, 2012 at 6:30 PM, Paul Anton Letnes < paul.anton.letnes@gmail.com> wrote:
On 21. des. 2012, at 16:53, David Cournapeau 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 [4]: import numpy as np
In [5]: from scipy import fft
In [6]: from scipy import fftpack
In [7]: d = np.linspace(0, 1e3, 1e7)
In [8]: %timeit np.fft.fft(d) 1 loops, best of 3: 1.29 s per loop
In [9]: %timeit fft(d) 1 loops, best of 3: 1.3 s per loop
In [10]: %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
On Fri, Dec 21, 2012 at 3:16 PM, Paul Anton Letnes <paul.anton.letnes@gmail.com> wrote: 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,
That is the same function; in scipy/__init__.py there's "from numpy import *". This is again for backwards compatibility only. You should not use anything from the main scipy namespace (except for running tests with scipy.test()). Ralf
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.
Cheers Paul
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
![](https://secure.gravatar.com/avatar/86ea939a72cee216b3c076b52f48f338.jpg?s=120&d=mm&r=g)
Den 21. des. 2012 kl. 16:16 skrev Paul Anton Letnes <paul.anton.letnes@gmail.com>:
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 [4]: import numpy as np
In [5]: from scipy import fft
In [6]: from scipy import fftpack
In [7]: d = np.linspace(0, 1e3, 1e7)
In [8]: %timeit np.fft.fft(d) 1 loops, best of 3: 1.29 s per loop
In [9]: %timeit fft(d) 1 loops, best of 3: 1.3 s per loop
In [10]: %timeit fftpack.fft(d) 1 loops, best of 3: 651 ms per loop
They are not the same. SciPy fftpack is fortran FFTPACK. NumPy uses the C coded fftpack-lite. The wrappers are also different, and SciPy can modify arrays inplace.
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.
If you use EPD, numpy.fft will use MKL. That will be about as fast as it gets. https://mail.enthought.com/pipermail/enthought-dev/2011-June/029299.html FFTW is GPL, but you can use it if GPL is ok. It usually is: If you can use Linux, you can use FFTW as well. ACML is also an option. It is not as fast as MKL or FFTW, but faster than FFTPACK. You can also call MKL, ACML or FFTW directly using Cython, f2py or ctypes. There is also a TVirtualFFT in ROOT, that uses FFTW. ROOT has a Python interface as well. Sturla
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Fri, Dec 21, 2012 at 4:14 PM, Sturla Molden <sturla@molden.no> wrote:
FFTW is GPL, but you can use it if GPL is ok. It usually is: If you can use Linux, you can use FFTW as well.
This is not true at all. The GPL on Linux does not impose any requirements at all on software that runs on Linux, mostly because they have an explicit exception on top of the GPL saying this. Using FFTW means that if you distribute your software, you almost certainly have to do it under the GPL or similar. This may or may not be a problem (you might not distribute, you might be fine with the GPL, etc.), but people should at least understand how licenses work. -n
![](https://secure.gravatar.com/avatar/86ea939a72cee216b3c076b52f48f338.jpg?s=120&d=mm&r=g)
Den 21. des. 2012 kl. 17:29 skrev Nathaniel Smith <njs@pobox.com>:
This is not true at all. The GPL on Linux does not impose any requirements at all on software that runs on Linux, mostly because they have an explicit exception on top of the GPL saying this. Using FFTW means that if you distribute your software, you almost certainly have to do it under the GPL or similar. This may or may not be a problem (you might not distribute, you might be fine with the GPL, etc.), but people should at least understand how licenses work.
If you distribute commercial software, you can get a commercial FFTW license. (MATLAB is one example. At least it used to include a non-GPL FFTW, it might use MKL now.) Sturla
participants (5)
-
David Cournapeau
-
Nathaniel Smith
-
Paul Anton Letnes
-
Ralf Gommers
-
Sturla Molden