Make all algorithms in cuda/std/algorithm available through cuda/std/algorithm.meow.h

[miscco]

We had a poll to see how users would like to access individual features of umbrella headers like <cuda/std/algorithm>

The vast majority preferred a pattern like <cuda/std/algorithms/find.h>

However, we can get away with finding a similar but different name if we use the pattern umbrella_header.feature

We can create a wrapper for the internal file and also instruct our IDE to ignore all files that match the pattern [a-z_]*\.[a-z_]* This works because we do not have any .h files in neither <cuda/> not <cuda/std/>

[miscco]

I am proposing to keep the current folder structure intact and only add symlinks EDIT: discussed this internally and we need real files for windows

For me this greatly improves maintainability of our code base. Otherwise there are 500+ files in <cuda/std/> and no proper way of organizing them

[jrhemstad]

I am proposing to keep the current folder structure intact and only add symlinks

I don't think symlinks work on Windows, do they?

[jrhemstad]

Given this is a pretty extensive product facing change, I'd like more thoughts from @wmaxey @griwes @gevtushenko @brycelelbach @ericniebler

[miscco]

I am proposing to keep the current folder structure intact and only add symlinks

I don't think symlinks work on Windows, do they?

They dont, moved to forwarding headers

[jrhemstad]

Some questions I'd like answered before we merge this:

• How will we test this? I think we should have tests that include each micro-header and ensure that was is supposed to be available in that header is indeed available.
• How will we document this?
• I'd like to see an evaluation of how well this naming pattern will extend to other headers

[miscco]

This isn't quite what I meant. I meant an analysis of how this pattern would extend to other headers like <cuda/std/type_traits> or similar. I don't want to adopt a special pattern that only applies to the <algorithm> header and doesn't scale to other headers where we'd need to use a different pattern. That inconsistency would be a bad user experience.

That is exactly what I meant. The chosen character does not appear in any source file name in the repository outside of the file extension

currently we only have [a-z_] as identifiers in the name and .[h, cuh] for the file ending.

As long as there is never a feature that we want to publicize named "h" and "cuh" we are fine.

The patter works perfectly fine with <cuda/std/type_traits.remove_cvref> or any other currently used header name

[bernhardmgruber]

I agree with @miscco here that . is probably a good choice.

Concretely, I'd like to see a list of other headers we may want to split up like this and evaluate how well the pattern extends to other headers.

That is still valuable to have independently. And it may give us new insight after all. @miscco can we gather a list of headers that would benefit from splitting as well? Like <type_traits>, <functional>, <cmath>, <iterator>, <utility>, ... Maybe also <atomic>, <chrono>, <memory>, <randpm>, <ranges>. Would the . work everywhere and "look & feel" ok?

[miscco]

Concretely, I'd like to see a list of other headers we may want to split up like this and evaluate how well the pattern extends to other headers.

I believe the candidates are:

• <cuda/cmath>
• <cuda/functional>
• <cuda/iterator>
• <cuda/memory>
• <cuda/numeric>
• <cuda/ptx>
• <cuda/random>
• <cuda/utility>
• <cuda/warp>
• <cuda/std/algorithm>
• <cuda/std/bit>
• <cuda/std/cmath>
• <cuda/std/concepts>
• <cuda/std/functional>
• <cuda/std/iterator> -> We only want to expose iterators and next and friends
• <cuda/std/memory>
• <cuda/std/numeric>
• <cuda/std/random>
• <cuda/std/ranges>
• <cuda/std/utility>
• <cuda/std/type_traits>

[bernhardmgruber]

I think we should have tests that include each micro-header and ensure that was is supposed to be available in that header is indeed available.

Can we have some really minimal tests for that?

[miscco]

@jrhemstad I have added tests to verify everything work with just the modularized includes, and it even found a bug 🎉

Any other questions?

[ericniebler]

i really do not like the naming scheme for the files. tooling very much cares about extensions. i don't expect this to be a great experience in an IDE, for example. and if we modularize all the headers listed in this comment from @Missco, then we'll have 100s of headers in cuda/std/.

The vast majority preferred a pattern like <cuda/std/algorithms/find.h>

then why aren't we using that?

[miscco]

The vast majority preferred a pattern like <cuda/std/algorithms/find.h>

then why aren't we using that?

The issue is that it is surprising and non-trivial. Note that we cannot do <cuda/std/algorithm/find.h> because <cuda/std/algorithm> is already a file not a folder.

So for every header we need to find a similar but not equal name for the original header which is really awkward. It also breaks down with e.g. <cuda/std/type_traits> What would be a good name for a subfolder?

I would also like to note that we have a bazillion files in our CI that are named meow.pass.cpp or even meow.compile.pass.cpp

[ericniebler]

So for every header we need to find a similar but not equal name for the original header which is really awkward.

so what? we can find the names. the cure you're suggesting is worse than the disease.

It also breaks down with e.g. <cuda/std/type_traits> What would be a good name for a subfolder?

<cuda/std/traits/is_integral.h> seems fine to me. or we can use the stable section names from the standard: <cuda/std/type.traits/is_integral.h>

[bernhardmgruber]

It also breaks down with e.g. <cuda/std/type_traits> What would be a good name for a subfolder?

<cuda/std/traits/is_integral.h> seems fine to me.

I disagree. I think discoverability of the single function headers is also very relevant for IDE usage, so if the user types #include <cuda/std/type_traits they should see in their auto-completion the <cuda/std/type_traits> header as well as all the single function headers.

Can't we just take the umbrella header and append a single character for the directory name? Like <cuda/std/type_traits_/is_integral>?

[brycelelbach]

I think we must do meow.suffix not algorithm.meow.

• Not having a suffix messes up syntax highlighting which is painful for users.
• It's probably also not great for AI agents. A suffix tells the AI agent what the file is without looking at it.

We should ideally use just one suffix for header names; let's go with whatever is most consistent with our current best practices. The options are .h, .hpp, .cuh; my understanding is that .cuh is considered best practice and what we try to use.

[github-actions]

🥳 CI Workflow Results

🟩 Finished in 1h 44m: Pass: 100%/108 | Total: 2d 06h | Max: 1h 23m | Hits: 83%/296842

See results here.