Modularized access to CCCL features

[miscco]

Life is good, you are coding / prompting away and then suddenly you need the minimum of 2 values.

The question arises: "Do I include 200k lines of pristine <cuda/std/algorithm> for a one line function?"

The same happens all the time.

• Want cuda::std::less? Then include all of <cuda/std/functional>
• Want cuda::std::pair? <cuda/std/utility> it is.

There are some headers like <cuda/std/array> that give you one thing and nothing more than that, but then there are umbrella headers that give you the thing you want and a thousand more.

Especially in the time of JIT compilation this rapidly becomes prohibitive. We have taken great steps inside of our libraries to only include what we absolutely need. But that does not alleviate the problem of umbrella headers.

To add insult to injury we are bound by the standard extensionless headers. I would love to have a <cuda/std/algorithm.h> then is an umbrella for <cuda/std/algorithm/find.h> and all its friends, but that ship has sailed a long time ago.

On the other hand. We cannot just make all the internal headers public. That would bind our hands for any future improvements of header hygiene and prevent us from removing unused internal headers that are not longer needed.

So this brings us to the following question:

[ahendriksen]

Thank you for starting this discussion @miscco. Compilation time is a topic dear to my heart.

CCCL provides a curated list of internal headers that are safe to access: e.g <cuda/std/__algorithm/find.h>

This option does not enable one to distinguish from the include path if the header is safe to access. I think that's bad.

CCCL provides similarly named folder like <cuda/std/algorithms/find.h> each umbrella has its own folder

Now that I see that this option has the most votes, I would suggest making the "similar name" easy to derive from the original header name. Preferably using a prefix or postfix, .e.g, algorithm_sub or pub_algorithm. The currently proposed naming scheme does not work for type_traits, which is already plural.

CCCL provides a unique folder e.g <cuda/std/mod/...> that contains all the headers we want to make public

I voted for this option initially because it satisfies the criteria that (1) the safety of access is derivable from the include path and (2) easy to derive.

[miscco]

Putting my maintainer head on this would also have the huge benefit that we do not pollute our repository with a bazillion files in the <cuda/std/> folder

[miscco]

@ahendriksen For option 2 we are currently leaning towards something like <cuda/std/algorithm_find.h> or <cuda/std/algorithm.find> or similar permutations

[ahendriksen]

@ahendriksen For option 2 we are currently leaning towards something like <cuda/std/algorithm_find.h> or <cuda/std/algorithm.find> or similar permutations

Both sound good to me. Very clear separation. We could do the same for cuda/ptx. I have a slight preference for <cuda/std/algorithm_find.h>. I think because it resembles existing naming conventions more.

[miscco]

yeah <cuda/ptx> is just gigantic and we had great results replacing that header with the ones we actually need

[bernhardmgruber]

#include <cuda/std/algorithm_find.h>

(with or without file extension) would have the advantage that I see the sub headers during auto-completion and may get curious about them ;) You could even name them <cuda/std/algorithm_just_find> :D

[miscco]