-
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 configurable capacity UniqueToken for #979. #3051
Add configurable capacity UniqueToken for #979. #3051
Conversation
Can one of the admins verify this patch? |
2c9e183
to
9b73f5c
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.
This is still failing on HPX. I will work on that, just a reminder not to merge.
using exec_space = ExecutionSpace; | ||
using size_type = typename exec_space::size_type; |
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 feel like you should deduce these from token_type
.
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.
done
bool ok = true; | ||
|
||
ok = ok && 0 <= t; | ||
ok = ok && t < tokens.size(); |
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.
Do these need to be atomic_and?
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.
No: this error check happens in each thread independently.
Limited to UniqueTokenScope::Instance specializations. Currently implemented for Serial, OpenMP, and Cuda execution spaces.
Both per-thread and per-team. Improve the testing of the configurable capacity version of UniqueToken to reflect the token per-team use case using the RAII helper.
11559c9
to
bd5f266
Compare
Fixed bug in Test for backends with concurrency>1 but max_team_size==1 Also addressed review comments
bd5f266
to
97c8d1b
Compare
Ran spotcheck on apollo:
|
Retest this please! |
Ah the HIP version is still missing. |
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.
Did you consider other names for your RAII-wrapper?
Retest this please |
void release(int) const noexcept {} | ||
/// \brief create object size for concurrency on the given instance | ||
/// | ||
/// This object should not be shared between instances |
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 have trouble parsing this comment. Please improve here and at places it was copied from.
Just copied what we've been using in our app code, no objections to changing it if you've got an alternative you'd prefer. |
Like @dalg24, I'm a bit uneasy with splitting the files, because it effectively means it isn't useable w/o #including Kokkos_AcquireUniqueTokenImpl.hpp (because they are functions in a templated type). Putting it in its own header would be much cleaner. The name isn't all that clear either "Guard" tends to indicate an RAII class, although I'm not sure a name like UniqueTokenGuard quite fits (although I could be wrong). Minor: I noticed that some of the namespaces are referenced as ::Kokkos::ns and others as Kokkos::ns. Any particular reason? It is unusual to reference them with a preceding ::. |
As a user I would love for Kokkos as a whole to have more headers that can be individually included, but my experience is that almost everything requires just including Kokkos_Core.hpp, and in the past I've been told that is really all Kokkos supports. Given that the existing Kokkos_UniqueToken.hpp only defines the base template and the specializations per execution space are in different headers I think getting to the point where any of this is useable without including Kokkos_Core.hpp is a bigger task? Personally I think ThreadUniqueToken and TeamUniqueToken might be the most clear names for the RAII helpers, and the existing UniqueToken might be better named UniqueTokenContainer? But there are probably backwards compatibility concerns there? Some of the existing UniqueToken implementation had the preceding ::Kokkos, I was just trying to be consistent with that. I was unsure if there was a general Kokkos policy about including that to avoid ADL or something? |
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.
Please
- move the declaration/definition of the RAII-wrappers in a separate header instead of the current workaround
- consider other names for the RAII-wrappers
- fix the typos
…ot of thoughts in
I added comments about the current points of friction in the design
@@ -677,15 +728,28 @@ class UniqueToken<Threads, UniqueTokenScope::Global> { | |||
UniqueToken(execution_space const & = execution_space()) noexcept {} | |||
|
|||
/// \brief upper bound for acquired values, i.e. 0 <= value < size() | |||
inline int size() const noexcept { return Threads::impl_thread_pool_size(); } | |||
KOKKOS_INLINE_FUNCTION | |||
int size() const noexcept { |
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 don't like this pattern of KOKKOS_ACTIVE_EXECUTION_MEMORY_SPACE_HOST in the Threads backend, but think it's a problem with our macros, not this implementation. Capturing here #3209
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.
Other than the comment (which I don't think is primarily about this PR) there are no obvious interface/implementation problems, and the functionality seems well tested
Retest this please |
Limited to UniqueTokenScope::Instance specializations. Currently
implemented for Serial, OpenMP, and Cuda execution spaces.
@crtrott