[SciPy-dev] fft benchmarks for new routines
Chuck Harris
Chuck.Harris at sdl.usu.edu
Mon May 12 09:24:41 CDT 2003
Hi Pearu,
> On 11 May 2003, Charles R Harris wrote:
>
> > I think my routines are better, not that I'm biased or anything.
> > They are faster, require only one work array for all transforms
> > below a given size, and the code is readable - not to say
> > understandable. 8)
>
> That's nice!
> Where one can see your routines?
I can send them to the list, or mail them to you direct. I do want to
check over the unrolled version first to make sure no sign errors
crept in --- I did verify that the original versions were correct.
They probably need some documentation too, as this is the
only code I know of that uses this algorithm.
>
> > To cut down on out-of-cache overhead, I unrolled a loop, which
> > made the code about 3x longer and somewhat ugly. The result is
> > a sort of bastard split radix 2,4 fft.
>
> What fft backend are you using in scipy? FFTPACK, FFTW, or DJBFFT?
What is DJBFFT?
I did my own based roughly on FFTPACK. It is not complete, as it
allocates and keeps the coefficient array and needs some locking
and reference counting to be thread safe. Don't know how to do this
in Python. Also, I only did the fft call (single and double precision),
and should probably add in the rest, along with the fast hartley transform
that I use for the real case. I renamed all the basic routines because
I got tired of spending half a minute to figure out just what the h*ll
drfftf stood for. This is now fft_dbl_real_for, and so on. Comments?
> Note that if your routines are power-two only then it would be still
They are power-two -- other radix values fail to move me ;)
By the way, one problem I had was that the *.so library (linux) was not
visible in the package, although it did fine as soon as I moved it up
into site-packages. Probably some obvious oversight on my part -- I
suspect the __init__.py file. Any thoughts?
Chuck
More information about the Scipy-dev
mailing list