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@physics.mcmaster.ca