On Tue, Oct 28, 2014 at 3:06 PM, David Cournapeau <cournape@gmail.com> wrote:
I
On Tue, Oct 28, 2014 at 2:31 PM, Nathaniel Smith <njs@pobox.com> wrote:
On 28 Oct 2014 07:32, "Jerome Kieffer" <Jerome.Kieffer@esrf.fr> wrote:
On Tue, 28 Oct 2014 04:28:37 +0000 Nathaniel Smith <njs@pobox.com> wrote:
It's definitely attractive. Some potential issues that might need
dealing
with, based on a quick skim:
In my tests, numpy's FFTPACK isn't that bad considering * (virtually) no extra overhead for installation * (virtually) no plan creation time * not that slower for each transformation
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).
The paper has lots of benchmark graphs, including measurements of setup time: http://anthonix.com/ffts/preprints/tsp2013.pdf
Nice. In this case, the solution may be to implement the Bluestein transform to deal with prime/near-prime numbers on top of FFTS.
I did not look much, but it did not obviously support building on windows as well ?
Ok, I took a quick look at it, and it will be a significant effort to be able to make FFTS work at all with MSVC on windows: - the code is not C89 compatible - it uses code generation using POSIX library. One would need to port that part to using Win32 API as well. - the test suite looks really limited (roundtripping only). The codebase does not seem particularly well written either (but neither is FFTPACK to be fair). Nothing impossible (looks like Sony at least uses this code on windows: https://github.com/anthonix/ffts/issues/27#issuecomment-40204403), but not a 2 hours thing either. David