[Numpy-discussion] Enhancements for NumPy's FFTs
Charles R Harris
charlesr.harris at gmail.com
Sat Mar 14 21:33:53 EDT 2009
On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden <sturla at molden.no> wrote:
>
> > Give it a shot. Note that the fft transforms also use int instead of
> > intp,
> > which limits the maximum transform size to 32 bits. Fixing that is
> > somewhere
> > on my todo list but I would be happy to leave it to you ;) Although I
> > expect
> > transforms > 2GB aren't all that common.
>
>
> By the way... When looking at fftpack.c there are two things that would
> likely improve the performance.
>
> 1) If we used ISO C (aka C99), arrays could be restricted, thus allowing
> more aggressive optimization. Now the compiler has to assume aliasing
> between function arguments. But as the C code is translated from Fortran,
> this is not the case.
>
We can't count on C99 at this point. Maybe David will add something so we
can use c99 when it is available.
>
> 2) In C, indexing arrays with unsigned integers are much more efficient
> (cf. AMDs optimization guide). I think the use of signed integers as array
> indices are inherited from Fortran77 FFTPACK. We should probably index the
> arrays with unsigned longs.
>
I don't have a problem with this, although I not sure what npy type is
appropriate without looking. Were you thinking of size_t? I was tempted by
that. But why is it more efficient? I haven't seen any special instructions
at the assembly level, so unless there is some sort of global optimization
that isn't obvious I don't know where the advantage is.
I always figured that a really good optimizer should derive the FFT if you
just give it the DFT code ;)
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090314/0e6f4922/attachment.html>
More information about the NumPy-Discussion
mailing list