On May 12, 2008, at 8:07 PM, David Cournapeau wrote:
eric jones wrote:
Hey David,
When we put the fft library together back in 2001-2002, there wasn't a good alternative for a fast fft package that wasn't GPLed. fftw was reasonably fast and fully functioning, but GPLed. fftpack had the functionality, but not the speed. djbfft (at the time) was noticeably faster than either of these for its important subset of functionality (radix 2), but wasn't full featured. The combination of djbfft and fftpack gave us a BSD compatible and fast library for SciPy. This was the combination that we used to build the binaries that were available from the scipy.org website.
Having been out of the building SciPy game for a while, my question would be, what fft libraries are used now to build the binaries for scipy.org? Are they using fftpack only? Hi Eric,
My understanding is that, at least for the windows binaries, only fftpack is used.
Ok. That is likely not optimal, but your other comments about speeding up the use of fftpack algorithms may ameliorate this issue while simplifying build.
I would guess that on linux, people use fftw3, since it is packaged by most distributions.
How do 3rd party Linux version packagers ( Redhat, Ubuntu, Suse, etc) package SciPy? Do they link against fftw or fftpack?
The problem is not a build issue per se. Because djbfft only supports 2^n, single dimension, we need to use another backend at the same time. Today, we support 4 backends (+ djbfft), which means I have to test 8 combinations (not 9 because when mkl is used, djbfft is not used at all). This, combined to the fact that every fft backend is different, makes moving forward more painful that I wished.
One option would be to just use djbfft with fftpack. This was the idea when it was added.
I think the speed issue is a bit moot, in the sense that right now, we do not use the backends very efficiently anyway. I started working on fftpack to get more speed (in place and out of place, float support, fftw plan control), but instead of improving the code, I am spending most of my time checking that I am not breaking any possible environment combination.
If it can be removed and we can keep the speed, that seems like a great win. If we loose the speed, I'd prefer just limiting djbfft to use with fftpack and disallowing the other combinations. eric
cheers,
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev