[SciPy-dev] scipy.fft module slow for complex inputs when linked to fftw3

David M. Cooke cookedm at physics.mcmaster.ca
Fri Aug 18 04:03:53 CDT 2006

On Fri, Aug 18, 2006 at 05:32:14PM +0900, David Cournapeau wrote:
> Hi there,
>     I noticed recently that when using the fft module of scipy, it is 
> much slower (5-10 folds) than numpy for complex inputs (only in the 1d 
> case) when linking to fftw3. This problem is reported on the ticket #1 
> for scipy : http://projects.scipy.org/scipy/scipy/ticket/1
> I am not sure, because the code is a bit difficult to read, but it looks 
> like in the case of complex input + fftw3, the plan is always recomputed 
> for each call to zfft (file:zfft.c), whereas in the real case or in the 
> complexe case + fftw2, the function drfft(file:drfft.c), called from 
> zrfft (file:zrfft.c) is calling a plan which is cached. I am trying to 
> see how the caching is done, but I am not sure I will have the time to 
> make it work for fftw3.

Well, for fftw3 it uses FFTW_ESTIMATE for the plan. So it does a cheap
estimate of what it needs. I tried changing it to FFTW_MEASURE,
but it went slower. I'd have to dig into fftw3's source to see how it
does the caching of wisdom.

Basically, after playing around, I still have no idea why it's slow.

> P.S: I am wondering if there is a reason why the code is written with 
> all those #ifdef ? Because it makes the hacking of the module quite 
> difficult. Why not implementing each function for each fft library, and 
> wraps them around in the header files ? Is is just a time constraint, or 
> is there another reason ?

I was looking at that code and was wondering the same thing :-) I'm
thinking of writing separate wrappers for each library, so you can get
at each one specifically (scipy.fftpack.impl.fftw3, for instance).
This would be a big win, I think, for fftw3, where it would then be
easier to handle the wisdom.

|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca

More information about the Scipy-dev mailing list