[SciPy-dev] Dropping djbfft ?
Mon May 12 23:22:37 CDT 2008
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
>> 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
>> the combination that we used to build the binaries that were
>> 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
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.
> Scipy-dev mailing list
More information about the Scipy-dev