> On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden <sturla@molden.no> wrote:

> There is also a ticket (#579) to add an implementation of the Bluestein
> algorithm for doing prime order fft's.  This could also be used for zoom
> type fft's. There is lots of fft stuff to be done. I wonder if some of it
> shouldn't go in Scipy? I think David added some dcts to Scipy.

I am not changing or adding algorithms for now. This is just to prevent
NumPy from locking up the interpreter while doing FFTs.

The loops that are worth multithreading are done in C in
fftpack_litemodule.c, not in Python in fftpack.py. I have added OpenMP
pragmas around them. When NumPy gets a build process that supports OpenMP,
they will execute in parallel. On GCC 4.4 is means compiling with -fopenmp
and linking -lgomp -lpthread (that goes for mingw/cygwin as well).

The init function seems to be thread safe. cffti and rffti work on arrays
created in the callers (fftpack_cffti and fftpack_rffti), no global
objects are touched.

I'm attaching a version of fftpack_litemodule.c that fixes most of what I
mentioned.