[SciPy-User] [ANN] pyfftw-0.2 released

Sebastian Haase seb.haase at gmail.com
Mon Feb 15 06:09:32 EST 2010


On Mon, Feb 15, 2010 at 12:06 PM, Sebastian Haase <seb.haase at gmail.com> wrote:
> On Mon, Feb 15, 2010 at 11:46 AM, David Cournapeau
> <david at silveregg.co.jp> wrote:
>> Sebastian Haase wrote:
>>
>>>
>>> Has this changed from FFTW2 to FFTW3 ?
>>> It would really limit the use of plans, and make overall FFTs much
>>> slower. In my specific case I very often have 512x512 single-precision
>>> real arrays (images), that I would do ffts over and over again. But
>>> the pointers would change ....
>>
>> You can, but you need to use the advanced plan API, or use the recently
>> added new-array execute function:
>>
>> http://www.fftw.org/fftw3_doc/New_002darray-Execute-Functions.html#New_002darray-Execute-Functions
>>
> so it sounds like the alignment is the "killer" argument for the whole idea:
> quote:
> """
> In general, only arrays allocated with fftw_malloc are guaranteed to
> be equally aligned (see SIMD alignment and fftw_malloc).
>
> The alignment issue is especially critical, because if you don't use
> fftw_malloc then you may have little control over the alignment of
> arrays in memory. For example, neither the C++ new function nor the
> Fortran allocate statement provide strong enough guarantees about data
> alignment. If you don't use fftw_malloc, therefore, you probably have
> to use FFTW_UNALIGNED (which disables most SIMD support). If possible,
> it is probably better for you to simply create multiple plans
> (creating a new plan is quick once one exists for a given size), or
> better yet re-use the same array for your transforms.
> """
>
> I guess this is really all new with version 3 of FFTW. I hope that
> "reating a new plan is quick once one exists for a given size" means
> "neglectable" for 512x512 arrays !?
>
> -S.
>
Oh, and it also seems to imply that FFTW3 is internally doing some
sort of plan-caching ... how else could it be faster the second time
!?
David, do you have experience regarding this topic - or anyone else here ?
-S.



More information about the SciPy-User mailing list