Ideas for reduction of binary sizes

[mreineck]

Since it was discussed in the last meeting, it might be helpful to have a list of options for reducing the size of the (cu)finufft binaries.

• do not instantiate single-precision spreadinterp functions for ns>8. We currently instantiate them up to ns=16, and as far as I can tell, it is mathematically impossible to call them for ns larger than (roughly) 8. This can save 25% of overall binary size.
• Cufinufft: do not instantiate spreadinterp methods for combinations of dimensionality and algorithm that are objectively slow (Example: 1D output-driven spreading). (These combinations are of course great for testing and should be available in principle, but there is no need to have them in production code.)
• Cufinufft: reduce the number of supported CUDA architectures?
• strip debug information? (We probably already do that for releases.)

Please add to this list if you have more ideas!

[DiamonDinoia]

• do not instantiate single-precision spreadinterp functions for ns>8. We currently instantiate them up to ns=16, and as far as I can tell, it is mathematically impossible to call them for ns larger than (roughly) 8. This can save 25% of overall binary size.

Is it not possible that low upsamp fact will use ns = 16 in float32? Does the aliasing error kill us in that case?

• Cufinufft: do not instantiate spreadinterp methods for combinations of dimensionality and algorithm that are objectively slow (Example: 1D output-driven spreading). (These combinations are of course great for testing and should be available in principle, but there is no need to have them in production code.)

It might sill be faster on some GPUs we cannot predict if there is a use case for it so I am not sure I want to go down this route unless really necessary.

• Cufinufft: reduce the number of supported CUDA architectures?

I would go down this route only if necessary

• strip debug information? (We probably already do that for releases.)

Yes, we do that but it can be improved.

I would say that using LTO also reduces size of binaries.

[mreineck]

Is it not possible that low upsamp fact will use ns = 16 in float32? Does the aliasing error kill us in that case?

I'm fairly sure that a practical limit is reached at ns=10 at the latest, even for upsampfact 1.25. After that, the dynamic range of the kernel will cause so much numerical error that no accuracy is gained by increasing ns.

It might sill be faster on some GPUs we cannot predict if there is a use case for it so I am not sure I want to go down this route unless really necessary.

OK ... it is a guarantee that at least 3/4 of every warp is idle and a synchronisation is needed after every NU point. That feels quite bad.
The nice thing about this approach is that it would also reduce compile time ... but perhaps we can get this with other approaches as well,

LTO can help with binary size, I agree.

[mreineck]

Small update on the ns limit for single precision:

In makeplan.hpp, maximum support is hardwired to 8 for single precision, if sigma<=1.4.
For higher sigma, I played around with this Python snippet, extracted from theoretical_kernel_ns() in kernel.cpp

import numpy as np

def get_ns_for_pswf(type, dim, sigma, tol):
    tolfac = 0.18 * 1.4**(dim-1)
    if type == 3: # compensate for type 3 worse (affects outer spread, not inner t2)
      tolfac *= 1.4;
    nsoff = 1.0  # width offset (helps balance err over sigma range)
    ns = int(np.ceil(
        np.log(tolfac / tol) / (np.pi * np.sqrt(1.0 - 1.0 / sigma)) +
        nsoff))
    return ns

For sigma>=1.4 and epsilon>=1e-7 I couldn't find any result larger than 11.

Not implementing the range from 12 to 16 may not sound like a big deal, but one has to consider that these functions may scale in size superlinearly with ns because of unrolling.

[mreineck]

... this may be extremely far-fetched, but I have seen a few other projects (like vkFFT) do this: how about not compiling the bulk of the Cuda code at all and just JITting it for exactly the right platform while the application is running on the user machine?
Does this also require the full Cuda toolkit?

[DiamonDinoia]

I would not open that can of worms. ckFFT would be massive with all the kernels for now I'd say that cufinufft is not so big that we need to do that.