FFTW bindings now implement numpy.fft interface
Some of you may be interested in the latest release of my FFTW bindings. It can now serve as a drop in replacement* for numpy.fft and scipy.fftpack. This means you can get most of the speed-up of FFTW with a one line code change or monkey patch existing libraries. Lots of other goodness too of course. Source here: https://github.com/hgomersall/pyFFTW pypi here: http://pypi.python.org/pypi/pyFFTW docs here: http://hgomersall.github.com/pyFFTW/ It's GPL3 due to license restrictions on FFTW. Get in touch if you want a different license and I'm sure we can reach an agreement ;) Cheers, Henry *In the case where the input array is not a numpy array, it doesn't work. This was an oversight and will be fixed in the next release. That said, if you're converting from a list on every transform, you have better optimisations than using FFTW. One other small caveat in a corner case to do with repeated axes - described in the docs.
Henry Gomersall wrote:
Some of you may be interested in the latest release of my FFTW bindings. It can now serve as a drop in replacement* for numpy.fft and scipy.fftpack.
This means you can get most of the speed-up of FFTW with a one line code change or monkey patch existing libraries.
Lots of other goodness too of course.
Source here: https://github.com/hgomersall/pyFFTW pypi here: http://pypi.python.org/pypi/pyFFTW docs here: http://hgomersall.github.com/pyFFTW/
It's GPL3 due to license restrictions on FFTW. Get in touch if you want a different license and I'm sure we can reach an agreement ;)
Cheers,
Henry
*In the case where the input array is not a numpy array, it doesn't work. This was an oversight and will be fixed in the next release. That said, if you're converting from a list on every transform, you have better optimisations than using FFTW. One other small caveat in a corner case to do with repeated axes - described in the docs.
The 1st example says:
import pyfftw import numpy a = pyfftw.n_byte_align_empty(128, 16, 'complex128') a[:] = numpy.random.randn(128) + 1j*numpy.random.randn(128) b = pyfftw.interfaces.numpy_fft.fft(a)
I don't see why I need to specify the alignment. The fftw library has a function to allocate aligned arrays that are allocated optimally. Why doesn't pyfft.n_byte_align_empty just align things correctly without me having to tell it the alignment?
On Sun, 2013-02-17 at 12:38 -0500, Neal Becker wrote:
The 1st example says:
import pyfftw import numpy a = pyfftw.n_byte_align_empty(128, 16, 'complex128') a[:] = numpy.random.randn(128) + 1j*numpy.random.randn(128) b = pyfftw.interfaces.numpy_fft.fft(a)
I don't see why I need to specify the alignment. The fftw library has a function to allocate aligned arrays that are allocated optimally. Why doesn't pyfft.n_byte_align_empty just align things correctly without me having to tell it the alignment?
No very good reason. When I started it was simply easier to have numpy handle the memory management, which is what is still used, and that precluded using FFTW's memory manager. It was all written when FFTW didn't support AVX and so basically 16-byte alignment was all that was needed. Extending to support 32-byte alignment was done in this framework because I deemed there were more important things to work on. It is possible to achieve the same result by replacing the alignment argument with pyfft.simd_alignment, which acquires the optimum alignment by inspecting the CPU (on x86/amd64). This isn't obvious from the tutorial, which is a deficiency borne of limited time. Why didn't I write a function that does that for you? I'm sure I had a good reason at the time ;) Consider this a 0.9.1 feature (i'll add an issue now). hen
participants (2)
-
Henry Gomersall -
Neal Becker