[SciPy-dev] Dropping djbfft ?
Mon May 12 20:07:41 CDT 2008
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?
My understanding is that, at least for the windows binaries, only
fftpack is used. I would guess that on linux, people use fftw3, since it
is packaged by most distributions.
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.
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
More information about the Scipy-dev