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

Cut down on the number of AccessTraits #967

Merged

Conversation

aprokop
Copy link
Contributor

@aprokop aprokop commented Nov 1, 2023

The goal is to avoid using AccessTraits internally in ArborX, only at the user interface functions. Motivated by #729, and in preparation for RangeTraits introduction.

@aprokop aprokop added the refactoring Code reorganization label Nov 1, 2023
@aprokop aprokop mentioned this pull request Nov 1, 2023
@aprokop aprokop force-pushed the access_traits_proliferation_primitives branch from 7c3118f to 15f9594 Compare November 1, 2023 14:40
@aprokop aprokop changed the title Cut down on the number of Access<Primitives, PrimitivesTag> Cut down on the number of AccessTraits<Primitives, PrimitivesTag> Nov 1, 2023
@aprokop
Copy link
Contributor Author

aprokop commented Nov 2, 2023

@dalg24 I checked performance using DBSCAN driver on A100 (both DBSCAN and MST), and have not observed any differences. Gitlab CI is clean too.

@aprokop aprokop force-pushed the access_traits_proliferation_primitives branch from 15f9594 to cd40a3d Compare November 3, 2023 17:15
@aprokop aprokop changed the title Cut down on the number of AccessTraits<Primitives, PrimitivesTag> Cut down on the number of AccessTraits Nov 3, 2023
@aprokop
Copy link
Contributor Author

aprokop commented Nov 3, 2023

Updated the PR to include AccessTraits<Predicates, PredicatesTag. Will check the performance again.

@aprokop
Copy link
Contributor Author

aprokop commented Nov 4, 2023

CUDA 11.0.3 has something weird

ptxas fatal   : Unresolved extern function '_ZN6ArborX12AccessTraitsIN6Kokkos4ViewIPNS_10IntersectsINS_3BoxEEEJNS1_6DeviceINS1_4CudaENS1_9CudaSpaceEEEEEENS_13PredicatesTagEvE3getERKSB_i'

(aka ArborX::AccessTraits<Kokkos::View<ArborX::Intersects<ArborX::Box>*, Kokkos::Device<Kokkos::Cuda, Kokkos::CudaSpace> >, ArborX::PredicatesTag, void>::get(Kokkos::View<ArborX::Intersects<ArborX::Box>*, Kokkos::Device<Kokkos::Cuda, Kokkos::CudaSpace> > const&, int))

This looks like a compiler bug, but I don't know how to fix.

Comment on lines +316 to +317
ArborX::Details::PairIndexVolume<Point>>
bvh(exec_space, ArborX::Details::LegacyValues<Points, Point>{points});
Copy link
Collaborator

Choose a reason for hiding this comment

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

This changes the leaf node type as well, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. Instead of storing boxes, it will now store points. It was an oversight from some previous PRs.

@@ -63,23 +63,23 @@ class BasicBruteForce
void query(ExecutionSpace const &space, Predicates const &predicates,
Callback const &callback, Ignore = Ignore()) const;

template <typename ExecutionSpace, typename Predicates,
template <typename ExecutionSpace, typename UserPredicates,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do you only change the name here and not in the other overloads? I would rather change the name in the implementation than in the interface. Maybe Predicates->PredicatesAccessor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed the name only here because we will wrap the provided predicates in AccessValues. In other places, where no wrapping is done, it does not matter.

I don't feel strongly either way.

src/ArborX_DBSCAN.hpp Show resolved Hide resolved
src/ArborX_DBSCAN.hpp Show resolved Hide resolved
@@ -199,16 +199,18 @@ void check_valid_access_traits(PrimitivesTag, Primitives const &,
}
}

template <typename Values>
template <typename Values, typename Tag = PrimitivesTag>
Copy link
Collaborator

Choose a reason for hiding this comment

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

If multiple tags can be used, I would rather not have a default value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about it. The thing is that in this case it would increase of size of this patch, as I would also have to change all places where I used AccessValues for primitives. I am not sure I want to do this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

As long as it's a separate commit, it's pretty clean/clear.

The goal is to avoid using AccessTraits internally in ArborX, only at
the user interface functions. In preparation for RangeTraits
introduction.
@aprokop aprokop force-pushed the access_traits_proliferation_primitives branch 2 times, most recently from aa590f6 to e70bd45 Compare December 7, 2023 00:39
@aprokop
Copy link
Contributor Author

aprokop commented Dec 7, 2023

DroppingAccessTraits<Predicates, PredicatesTag> from this PR. This should avoid CUDA-11.0.3 build issue, and unlock #969.

@aprokop
Copy link
Contributor Author

aprokop commented Dec 7, 2023

Everything passes except HIP OOM.

@@ -263,8 +239,8 @@ dbscan(ExecutionSpace const &exec_space, Primitives const &primitives,
{
Kokkos::Profiling::pushRegion("ArborX::DBSCAN");

using Access = AccessTraits<Primitives, PrimitivesTag>;
using MemorySpace = typename Access::memory_space;
using Points = Details::AccessValues<Primitives>;
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the reasoning for the parameters naming in DBSCAN?
It went for Primitives/Points as compared to the spatial indexes where we did UserValues/Values.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK I see below that we assert the value type is point.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Generally, I try to name the variables based on the context. In DBSCAN, the values are points and nothing else. Spatial indexes have to deal with unknown values, and I thus call them UserValues. I use Primitives as something that has valid AccessTraits as a rule of thumb, to indicate that it uses the old interface.

src/details/ArborX_MinimumSpanningTree.hpp Show resolved Hide resolved
@aprokop aprokop merged commit 5a8d82e into arborx:master Dec 7, 2023
1 of 2 checks passed
@aprokop aprokop deleted the access_traits_proliferation_primitives branch December 7, 2023 14:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Code reorganization
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants