On Sat, Mar 14, 2009 at 7:02 PM, Sturla Molden <stu...@molden.no> wrote:
> > On Sat, Mar 14, 2009 at 3:58 PM, Sturla Molden <stu...@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. > Well, I was hoping to get you sucked into doing some work here ;) > > 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. > Can you put it somewhere for review? I don't think this should go into 1.3 at this late date but 1.4 is a good chance. Hopefully we will get the next release out a bit faster than this one. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
