[SciPy-dev] Dropping djbfft ?

[eric jones]

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
>