You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the distant future, clij2-fft and other projects might be a good subject for further study. For example, I'd be interested in the overhead that is incurred by calling clfft from java.
The text was updated successfully, but these errors were encountered:
:-D interesting thread. Great to hear that people are interested in FFTs. Our data doesn't support a few of the claims made, but
that motivates us to continue.
It's a shame that clfft doesn't see continued investment. We've kept it in the loop for backwards compatibility. With Intel
going for oneAPI/Sycl/DPC++ and AMD investing in ROCM, I fear that we soon see more FFT libs coming to live. rocFFT is already a
thing:
https://github.com/ROCmSoftwarePlatform/rocFFT (Linux only for now AFAIK)
Fortunately, @zyzzyxdonta is working on extending gearshifft (with an HPC focus though). So if this community has any wishes on
what we can improve, let us know! Our motivation for gearshifft always was to spare people the time to benchmark their beloved
FFT code to competitors.
Hi folks,
great to see this coming to live. Just wanted to share our benchmark for FFT libraries:
https://github.com/mpicbg-scicomp/gearshifft
and the viz of the current results are available here
https://www.kcod.de/gearshifft/
which include numbers for clfft.
In the distant future, clij2-fft and other projects might be a good subject for further study. For example, I'd be interested in the overhead that is incurred by calling clfft from java.
The text was updated successfully, but these errors were encountered: