On Sat, Mar 14, 2009 at 7:23 PM, Sturla Molden <stu...@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
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
