On Thu, Dec 11, 2008 at 10:55 PM, Gabriel Beckers <beckers@orn.mpg.de> wrote:
> Hi,
>> I see that in the new scipy (0.7) only fftpack (NETLIB) remains for fft.
> I understand the reasons for this, but for my application (filtering
> gigabytes of neurophysiological data) fft speed differences really lead
> to very significant speed differences.
What it the dimensions of your fourier transforms ? The use of fftw in
scipy was far from optimal for various reasons, so I am a bit
surprised about the very significant part.
>> What would the best way of using fftw, now that the wrappers are gone.
Reusing the removed code from scipy into your own package would be one
solution. Ideally, I should have put this code into a scikit, but this
would have required some work to be in an acceptable shape.
If you are willing to spend some time on it, I would certainly welcome
a good wrapper around fftw put into a scikit.
> Cython?
Cython would be a bit difficult because it lacks complex support (more
exactly, it cannot translate yet into C99 complex numbers; it should
be possible to circumvent the problems). If you only need real to real
transforms, I think cython would be a quick way to do it. That's
certainly how I would do it if I had to.
If you really care about speed, you should tweak you allocation scheme
to force aligned allocation: it will give you a factor 2 speed
increase in many cases - it is difficult to do in a cross platform
manner, but trivial in a particular case/platform (since fftw has such
an allocator).
cheers,
David