Benchmark Suite

[tknopp]

I open this issue for discussions around the benchmark suite located here:
https://github.com/JuliaMath/NFFT.jl/tree/master/benchmark

The results are automatically integrated into our documentation
https://juliamath.github.io/NFFT.jl/dev/performance/

My idea would be to have a quick overview about where we stand instead of a pages long detailed benchmark comparison. However, I am open for integrating more cases, e.g.:

• 1D, 2D, 3D
• sparse NFFTs as are often used in MRI/Compressed Sensing

At some point also the GPU implementations would be nice to compare.

[aTrotier]

Hi great job, Something interesting might be to benchmark the memory consumption for each package. We are often limited in our research by that points and we are willing to take more time to reconstruct an image in exchange of a low memory mod. Le lun. 31 janv. 2022 à 00:14, Tobias Knopp ***@***.***> a écrit :

…

I open this issue for discussions around the benchmark suite located here: https://github.com/JuliaMath/NFFT.jl/tree/master/benchmark The results are automatically integrated into our documentation https://juliamath.github.io/NFFT.jl/dev/performance/ My idea would be to have a quick overview about where we stand instead of a pages long detailed benchmark comparison. However, I am open for integrating more cases, e.g.: - 1D, 2D, 3D - sparse NFFTs as are often used in MRI/Compressed Sensing At some point also the GPU implementations would be nice to compare. — Reply to this email directly, view it on GitHub <#76>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5P7OZ6ULVL4S53H7P6HJ3UYXA5BANCNFSM5NE3HNGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tknopp]

Yes good point. This will be more difficult to benchmark across packages though. We probably should just do what has been done in table 6.2 of https://arxiv.org/pdf/1808.06736.pdf.

In our case it should be about

   2*|σ*N|*sizeof(Complex{T}) + 2*M*D*(sizeof(T) + sizeof(Int64)) + D*LUTSize*3*sizeof(T)

which would give about 30 GB for the case reported in the paper. But there is some room for reducing that.