Re: FFT proposal for gsoc 2021

From: Eduardo Quintana (eduardo.quintana_at_[hidden])
Date: 2021-03-30 17:01:34

 ('
' encoding is not supported, stored as-is)
Hi Stefan,

> Your schedule above looks very ambitious, and, I fear, quite unrealistic:

You're right about the timeline: it is too ambitiuos.
Though some work it is already done and it only needs polishing.
Anyways I'll make it shorter, maybe by scrapping out the multi-threading part
for post-GSOC work.

> For that reason, as well as for reasons I already outlined in a previous
> post, I strongly suggest you change the ordering (and timing) of your
> milestones, to first focus on an API that can be implemented as a
> wrapper around FFTW (as I suspect that will be the implementation most
> developers will use until you have an alternative that actually
> out-performs FFTW), and only then start to re-implement your API with
> other backends (including your own).

Wrapping FFTW is not a priority I have. I believe that the right way to work
towards an FFTW/C++ api will be to do so directly into the FFTW project. Sooner
or later someone will do it.

What I want to bring to Boost.Math are "Generic Programming" FFT algorithms
for situations that FFTW can't handle. And I want them to have decent
performance for complex numbers, I do not aim to outperform FFTW.
With time it can be improved and one day it will become competitive with FFTW.
In part, the success of the FFTW is due to the "codelets", which are functions
for small and fixed-size FFTs that they generate from a C code
that is generated by a program called "genfft". I believe we can do better with
C++ compile-time programming. Not for this summer though...

Thanks for the feedback.
Eduardo