[SciPy-dev] Dropping djbfft ?

David Cournapeau david@ar.media.kyoto-u.ac...
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?
Hi Eric,

    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 
combination.

cheers,

David


More information about the Scipy-dev mailing list