Split batched solver compilation

[MarcelKoch]

This PR splits up the compilation of the batched solvers in order to reduce the compilation times. It splits up the instantiations of the kernel launches depending on the number of vectors in shared memory. This is based on the same CMake mechanism as for the csr and fbcsr kernels.

[upsj]

This should have a huge impact, excerpt from the HIP 5.14 debug build log

6534.89 hip/CMakeFiles/ginkgo_hip.dir/solver/batch_bicgstab_kernels.hip.cpp.o

[MarcelKoch]

the template here (and in the other macros below) could be removed, if the value/index type instantiation macros would accept variable number or arguments.

[MarcelKoch]

That doesn't work until C++20. A macro with (arg, ...) requires two arguments before c++20.

[pratikvn]

In general, the idea looks good, but the pipelines are failing.

One thing against this approach is the readability and maintainability is seriously affected. The already complex batched code is even more complex and annoying to read now. We should maybe see if instead we dont do this split approach and instead maybe do what Jacobi does and have fewer cases as default, and only have full instantiations when necessary.

[MarcelKoch]

IMO the Jacobi instantiation is more complex than what is here. The kernel and the instantiations are directly together, instead of being generated by CMake, which makes it easier to follow for me.
I also merged the two .cpp files per solver, perhaps that can simplify things a bit again.

But I agree that the batch system needs an overhaul in general.

[pratikvn]

An alternative approach: https://github.com/ginkgo-project/ginkgo/tree/batch-optim

[MarcelKoch]

An alternative approach: https://github.com/ginkgo-project/ginkgo/tree/batch-optim

This seems to be quite orthogonal to this PR. With full optimizations enabled, there would be the same issue as before, so the fix from this PR is still needed. I don't see a reason why we should burden people that want the full optimizations enabled with those long compile times, for which we already have a fix available.
But we could add this into this PR.

[pratikvn]

@MarcelKoch, can you please rebase this when you have some time and we can try to get it merged ?

[yhmtsai]

I think it will lead issue with single mode

[yhmtsai]

It will not work with GINKGO_DPCPP_SINGLE_MODE=ON.
we use the instantiation to provide the specialization with unsupported exception on double precision.
with GKO_BATCH_INSTANTION, it will be wrong. Only the last one has the specialization, but the others will be instantiated.
template macro {GKO_UNSUPPORTED;} ->

template first_...;
template second_...;
...
template last  {GKO_UNSUPPORTED;}

[MarcelKoch]

You're right. Thanks for bringing this up. I changed the order of macro application, so now it should be fixed.

[pratikvn]

I would wait for the CI to finish to merge this (maybe also the Intel SYCL pipelines), but looks good to me otherwise.

[pratikvn]

I think first one is everything in shared memory, second one is nothing in shared memory.

[pratikvn]

Just a comment and something for me to do in the future: I think this whole logic needs to be simplified. It seems it is now also possible to set the max number of registers similar to the launch_bounds with CUDA: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#maximum-number-of-registers-per-thread

But of course, that means we maybe cannot unify HIP and CUDA anymore, but something we need to investigate.

[yhmtsai]

LGTM. It is a bit hard to understand now though.

[sonarcloud]

Quality Gate failed

Failed conditions
27.3% Duplication on New Code (required ≤ 20%)

See analysis details on SonarQube Cloud