Re: FFT proposal for gsoc 2021

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2021-03-14 18:18:04

 > At the risk of starting a long and fundamental> discussion about Boost's fundamental goals,
> ...

> 1) Develop a C++ API that can be used as> a thin layer over one or two existing FFT> "backend" libraries (FFTW seems a natural choice).

> 2) Implement that same API "from scratch",> but without much effort put into performance.> The goal isn't to out-perform existing implementations> (which would take many years of effort !),> but to provide a functionally complete and> correct reference implementation, useful for testing.
Yes. Indeed, your 1 and 2 are exactly consistentwith my own subjective personal thoughts.
Thatreally seems rather just sensibleto me.

Many thanks and kind regards, Chris

    On Sunday, March 14, 2021, 6:19:35 PM GMT+1, Stefan Seefeld via Boost <boost_at_[hidden]> wrote:  
 
 
On 2021-03-11 1:55 p.m., Christopher Kormanyos via Boost wrote:
>Â  > Hi Boost community,
>> I've been working on a C++ templated library> for Fast Fourier Transforms
>> ...
>> Is there anyone interested in supervising this> project? Any opinions?
> Thank you for your interest and query.
>
> Yes. I think I am interested and potentially qualifiedas 5 time GSoC mentor in Multiprecision and Math.
> The plan seems good, start with header onlysimple implementation and increase complexityand efficiency as time allows.
> This project would fill a present gap and wish listentry in Math/Multirpecision for those unable/unwillingto include FFTW.
> I will write a little project description at rthe relevantpage, link will follow...

At the risk of starting a long and fundamental discussion about Boost's 
fundamental goals, I'd like to suggest that we step back a little to 
consider different options. Reimplementing FFTs from scratch might be 
didactically useful for the person(s) doing that, but for the developer 
community not be of much interest if the quality of the result doesn't 
match already available options. And to think that you can match freely 
available FFT implementations (which have often evolved over decades) 
seems foolish.

In that sense, the goal should *not* be to come up with a new and 
competitive implementation of an FFT library.

Rather, I would like to propose a slightly different approach:

1) Develop a C++ API that can be used as a thin layer over one or two 
existing FFT "backend" libraries (FFTW seems a natural choice).

2) Implement that same API "from scratch", but without much effort put 
into performance. The goal isn't to out-perform existing implementations 
(which would take many years of effort !), but to provide a functionally 
complete and correct reference implementation, useful for testing.

This would open the door for future additions of other back-ends, useful 
for developers who are unable or unwilling to use the primary back-end 
itself.

(Note that the selection of the backend could be done at compile-time or 
at runtime, depending on the available hardware, including GPUs or other 
accelerators. Designing a clever dispatch mechanism to pick the "best" 
backend given a particular problem set (problem size, data types, data 
layout, etc.) is itself a complex problem worth considering...)

---
In a nutshell, the goal should be a modern C++ API that is convenient to 
use and which can be bound to different backends for top performance, 
yet avoiding explicit dependence on specific implementations.
Stefan
-- 
      ...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost