Skip to content
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

Remove fancy iterators #852

Merged
merged 24 commits into from
Jul 7, 2024
Merged

Remove fancy iterators #852

merged 24 commits into from
Jul 7, 2024

Conversation

elalish
Copy link
Owner

@elalish elalish commented Jun 25, 2024

This refactor will aid #823 - by removing zip iterators all we'll need is a counting iterator, which will reduce the amount of Thrust we rely on. Frankly, I also feel like this cleans up the code a little anyway - I always hated those tuples.

I've only done a few files so far, but it's going pretty quickly. Should be no big deal - just wanted to show my progress.

@elalish elalish self-assigned this Jun 25, 2024
@elalish
Copy link
Owner Author

elalish commented Jun 25, 2024

@pca006132 Before I go too much further, do you have a sense of how much conflict this will generate with #833? Perhaps we should merge that first if it's ready soon.

@elalish elalish mentioned this pull request Jun 28, 2024
@elalish elalish changed the title Remove fancy iterators [WIP] Remove fancy iterators Jul 2, 2024
@elalish elalish requested a review from pca006132 July 2, 2024 21:38
@elalish
Copy link
Owner Author

elalish commented Jul 2, 2024

Okay, I've removed zip iterators completely and done some other cleanup, like removing reduce_by_key. The main iterator thing that's left is a few usages of transform_iterator which can probably be taken care of more easily in #823.

@pca006132
Copy link
Collaborator

Nice, will review later.

Copy link
Collaborator

@pca006132 pca006132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not many comments here, I just had a glimpse over it. The new code is easier to read, which is always a nice bonus when we refactor our code :)

Will work on implementing the transform iterator, as well as maybe give some simple benchmark result to see if this is having unexpected impact on performance considering we change those sort on zip iterators to sort + permute

@@ -154,15 +154,13 @@ struct CreateRadixTree {

template <typename T, const bool selfCollision, typename Recorder>
struct FindCollisions {
VecView<const T> queries;
VecView<const Box> nodeBBox_;
VecView<const thrust::pair<int, int>> internalChildren_;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking if we can remove this thrust::pair as well, maybe with std::pair?
Not really related to fancy iterator, but I feel that the reason for using thrust::pair is mostly because of zip.

if (reverse)
transform(policy, w03.begin(), w03.end(), w03.begin(),
thrust::negate<int>());
for_each_n(policy, countAt(0), s02.size(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is much simpler!

stable_sort(
policy, ids.begin(), ids.end(),
[&edge](const int& a, const int& b) { return edge[a] < edge[b]; });

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious if we can skip the edge tmp buffer completely, and compute the edge information on-the-fly. Maybe we can try a benchmark later, not critical.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I never liked that either; I couldn't find another way before, but if you have an idea, that would be great.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: I tried this, it is slightly slower.

@pca006132
Copy link
Collaborator

And a general comment: maybe we should use std::pair whenever possible? I don't see the need to use thrust::pair now.

@pca006132
Copy link
Collaborator

FYI: there is basically no performance different.

@pca006132
Copy link
Collaborator

It seems that thrust is doing something non-trivial in their copy function, causing issues with our simple custom iterator implementations. I don't want to dig into the details of that as we will be getting rid of them later anyway, so I just switch to the sequential implementation for now if there is no pstl support.

@pca006132 pca006132 mentioned this pull request Jul 7, 2024
@elalish
Copy link
Owner Author

elalish commented Jul 7, 2024

Thank you, this looks excellent! Let's go ahead and merge this and remove thrust::pair and such in the follow-up.

@pca006132
Copy link
Collaborator

actually that was done in another PR :)

@elalish elalish merged commit ddb3cbe into master Jul 7, 2024
19 checks passed
@elalish elalish deleted the banishIterators branch July 7, 2024 15:37
@elalish elalish mentioned this pull request Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants