Re: [Numpydiscussion] numpy FFT memory accumulation
At 10:57 PM 11/1/2007, Charles R Harris wrote:
An additional complication is that I pass the numpy (or Numeric) array address to the ctypes library call so that the data is placed directly into the array from the call. I use the if/else end wrap logic to determine whether I need to do a split and copy if the new data wraps.
OK. Hmm, I wonder if you would lose much by taking a straight forward radix2 fft and teaching it to use modular indices? Probably not worth the trouble, but an fft tailored to a ring buffer might be useful for other things.
The problem is, I once compiled my own FFT dll to call from Python and it was 2x slower than FFTPACK  I'm not mathsmart enough to make all of the caching and numerical shortcuts. That, and Intel's optimized FFT is 3x faster than FFTPACK... I may still try to do a "zoom/range FFT" which does not compute all bins, and maybe only with a sine transform, which (I think) should be sufficient to determine peak real frequency and maybe use fewer cycles.
Probably the easiest thing is to just copy the ring buffer out into a linear array.
I do that for the bufferwrap condition, while simply assigning a slice (no copy) to the temp array otherwise.
I used Numeric functions for the ~40% speed increase, but I don't
I know that numarray was slow in creating small arrays, but is Numpy really that bad compared to Numeric?
I just saw the # of FFTs/sec go from 390 to 550 just by switching numpy to Numeric (Intel Core Duo). Add a timer to my previous code posts and see how your results look. For the megaarrays a lot of the numpy developers work with it is much faster, and I now find Numeric is lacking many other niceties, like frombuffer(). Ray  No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.18/1104  Release Date: 11/1/2007 6:47 PM
participants (1)

Ray Schumacher