-
Notifications
You must be signed in to change notification settings - Fork 407
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
Add UnorderedMapInsertOps for coo2crs #5877
Conversation
Apparently, this fails on the |
3eba2a7
to
10d9942
Compare
Looks like there is still a segfault (at least for |
bc33872
to
9447ad0
Compare
9447ad0
to
3522dfe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposed approach is a breaking change: why can't we just have an insert function overload which takes an op, or add a insert_accumulate function?
Kokkos::View<std::remove_const_t<std::conditional_t< | ||
std::is_void_v<Value>, int, Value>> *, | ||
Device>, | ||
uint32_t>::NoOp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a template parameter is a breaking change we can't do that really. We could discuss adding this only if deprecated code off, but we can't simply add it. Alternatively, why can't we have an overload of insert which takes an insert op? Is there a reason this has to be a global template for the class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like the lightest-weight way to add this operation as well as following the implementation style of UnorderedMap. What about keeping the current approach with a single constructor overload, rather than a new insert method, the constructor overload could include the InsertOp type and constructor parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this more now, I see no reason for making the InsertOp a global template for the class other than following the existing implementation style of UnorderedMap (e.g. EqualTo, etc.). I will try refactoring with a new insert method instead. Can you elaborate on how the InsertOp template parameter is a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After trying to remove the InsertOp as a global template parameter, I found that deep copy no longer works. I will look into using insert method overloads rather than a class member.
@@ -532,6 +593,7 @@ class UnorderedMap { | |||
} | |||
|
|||
result.set_existing(curr, free_existing); | |||
if (!is_set) m_insert_op.op(m_values, curr, &v); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this is the only place where this is used. I think we can just have an overload of insert which takes the insert op. Or maybe even have a different name: insert_accumulate or so. Do you see any issue with that approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only issue I see would be a lot of duplicate code.
3522dfe
to
2177292
Compare
Needs a rebase. Question at everyone but especially @masterleinad @nmm0 @nliber @dalg24: Do we like the way the insert ops are grouped here mechanically as nested classes in a separate class? There are alternatives:
At least we should check for where we do other stuff like that and what approach we take so we can end up with a consistent way of doing this. |
Oh just to confirm: the overload approach of insert with a default insert mechanism is good now. |
I guess one question is whether we want this to be a point of customization. I'm not saying we should but if we want additional ops to be added we can't use it in a nested class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a test for void
value'd maps (i.e. sets)? What is the expected behavior of the ops when value is void
?
Hi @nmm0. Thanks for your review. The op is not executed when the map is void value'd due to |
Co-authored-by: Daniel Arndt <arndtd@ornl.gov>
Fix OpenMP test failures Fix CI build error Increase size of expected_values
Thanks for the clarification! Let's then do: if constexpr (!is_set) {
arg_insert_op.op(m_values, curr, v);
} Then we don't have to worry about it compiling with a set. Also, in that case, I think we should probably not allow the op to be even specified if inserting into a set. This is something we probably need to deal with now, because if a user specifies an InsertOp for a set and we clean up the interface later then it would be a breaking change. I'd like to get other people's opinion on it but one suggestion would be to just do a static_assert, which would be a quick fix rather than making an overload: if constexpr (is_set) {
static_assert(std::is_same_v<InsertOpType, default_op_type>);
} |
Ensure m_insert_op gets copied too
87c3691
to
c265bdb
Compare
The Jenkins SYCL-OneApi failure is unrelated to these changes:
Full console: https://cloud.cees.ornl.gov/jenkins-ci/blue/rest/organizations/jenkins/pipelines/Kokkos/runs/12424/nodes/49/steps/252/log/?start=0. |
The Jenkins SYCL-OneApi failed again:
Can anyone confirm that this failure is unrelated to these changes? |
I would think that the failure is unrelated; the test is not using |
Co-authored-by: Daniel Arndt <arndtd@ornl.gov>
I think this is ready to merge. The OpenMP Target CI failure in Jenkins appears to be unrelated to these change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me.
@crtrott did you get satisfactory feedback on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready depending on what we decide for the convention for Ops
However it needs a changelog entry (4.1) and a corresponding PR for the docs
Thinking about Christian's question some more now and in particular how ScatterView handles insertion operators, we should be consistent if possible. @nmm0, @dalg24: Is ScatterView the only other container that supports "operations" in Kokkos core? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding docs and changelog!
It looks like ScatterView has the concept of a |
Retest this please |
1 similar comment
Retest this please |
Rerunning the tests, since it looks like Jenkins had a hiccup |
Retest this please |
GCC 8.4.0 timed out and the SYCL-OneApi test failed again:
|
To implement the sparse conversion kernel, coo2crs, I would like to have duplicate key insertions accumulate values in a
Kokkos::UnorderedMap
. This PR addsUnorderedMapInsertOps::AtomicAdd
andUnorderedMapInsertOps::NoOp
(the current insertion behavior for duplicate keys).Related to kokkos/kokkos-kernels#1164.
Going forward, I would also like to extend
Kokkos::UnorderedMap
to support shared memory and addUnorderedMapInsertOps::Overwrite
.