Skip to content

[FEA] Add iterator wrapping a T* with a custom element stride #3698

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bernhardmgruber opened this issue Feb 5, 2025 · 3 comments · Fixed by #4014
Closed

[FEA] Add iterator wrapping a T* with a custom element stride #3698

bernhardmgruber opened this issue Feb 5, 2025 · 3 comments · Fixed by #4014
Assignees

Comments

@bernhardmgruber
Copy link
Contributor

bernhardmgruber commented Feb 5, 2025

To run CUB/thrust algorithms on a single data member of an array of structs, we would need an iterator that wraps a pointer to that data member (T*), but advances a different stride than sizeof(T).

Contrived example use case:

struct rgb { float r, g, b; };

std::vector<rgb> image = ...;
float* first_red = &image[0].r;
// ++first_red would advance to image[0].g
auto it = striding_iterator<float, sizeof(rgb)>{first_red};
// ++it would jump to image[1].r
auto sum_red = thrust::reduce(host, it, it + image.size());
@miscco
Copy link
Contributor

miscco commented Feb 5, 2025

I am wondering whether it would be better to ensure that thrust::transform_iterator can work with projections like ranges::transform

@bernhardmgruber
Copy link
Contributor Author

I am wondering whether it would be better to ensure that thrust::transform_iterator can work with projections like ranges::transform

I agree, but I tried that in the past (#2006) and the problem is that thrust::transform_iterator wraps a lot of thrust::device_pointer<T> returning thrust::device_reference<T>, so we would need to make cuda::std::invoke(ptr, &rgb::x) work on a thrust::device_pointer<T>.

@bernhardmgruber
Copy link
Contributor Author

bernhardmgruber commented Mar 5, 2025

It turns out counting_iterator<Incrementable> can almost solve this, since the Incrementable can be a pointer and #4014 proposes a custom step. We just need to add a dereference twice.

@bernhardmgruber bernhardmgruber self-assigned this Mar 5, 2025
@cccl-authenticator-app cccl-authenticator-app bot moved this from Todo to In Progress in CCCL Mar 5, 2025
@cccl-authenticator-app cccl-authenticator-app bot moved this from In Progress to In Review in CCCL May 20, 2025
@bernhardmgruber bernhardmgruber moved this from In Review to In Progress in CCCL May 21, 2025
@github-project-automation github-project-automation bot moved this from In Progress to Done in CCCL May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants