<p dir="ltr">On 28 Oct 2014 07:32, "Jerome Kieffer" <<a href="mailto:Jerome.Kieffer@esrf.fr">Jerome.Kieffer@esrf.fr</a>> wrote:<br>
><br>
> On Tue, 28 Oct 2014 04:28:37 +0000<br>
> Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
><br>
> > It's definitely attractive. Some potential issues that might need dealing<br>
> > with, based on a quick skim:<br>
><br>
> In my tests, numpy's FFTPACK isn't that bad considering<br>
> * (virtually) no extra overhead for installation<br>
> * (virtually) no plan creation time<br>
> * not that slower for each transformation</p>
<p dir="ltr">Well, this is what makes FFTS intriguing :-). It's BSD licensed, so we could distribute it by default like we do fftpack, it uses cache-oblivious algorithms so it has no planning step, and even without planning it benchmarks as faster than FFTW's most expensive planning mode (in the cases that FFTS supports, i.e. power-of-two transforms).</p>
<p dir="ltr">The paper has lots of benchmark graphs, including measurements of setup time:<br>
  <a href="http://anthonix.com/ffts/preprints/tsp2013.pdf">http://anthonix.com/ffts/preprints/tsp2013.pdf</a></p>
<p dir="ltr">-n</p>