-
Notifications
You must be signed in to change notification settings - Fork 208
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
Refactor rmm::device_scalar
in terms of rmm::device_uvector
#789
Refactor rmm::device_scalar
in terms of rmm::device_uvector
#789
Conversation
rmm::device_scalar
in terms of rmm::device_uvector
T const &initial_value, | ||
cuda_stream_view stream = cuda_stream_view{}, | ||
value_type const &initial_value, | ||
cuda_stream_view stream, |
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.
Why remove the default? It seems that it would be a common use case to use the default stream, especially with PTDS enabled.
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.
Because we want to make all stream-ordered APIs explicit. See e.g. #418. Note that device_uvector
and now device_buffer
have no default stream parameters.
RMM_CUDA_TRY( | ||
cudaMemcpyAsync(element_ptr(element_index), &v, sizeof(v), cudaMemcpyDefault, s.value())); | ||
s.synchronize_no_throw(); | ||
if constexpr (std::is_fundamental<value_type>::value) { |
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.
Maybe this can be done using SFINAE?
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.
It certainly can, but why would I want to go back to SFINAE? I replaced SFINAE with if constexpr
, which allows having a single implementation of this function rather than three!
include/rmm/device_scalar.hpp
Outdated
using value_type = T; | ||
using reference = value_type &; | ||
using const_reference = value_type const &; | ||
using pointer = value_type *; | ||
using const_pointer = value_type const *; | ||
using iterator = pointer; | ||
using const_iterator = const_pointer; |
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 would define these in terms of device_uvector
. Also, I don't think the iterator
typedefs are needed for device_scalar
?
using value_type = T; | |
using reference = value_type &; | |
using const_reference = value_type const &; | |
using pointer = value_type *; | |
using const_pointer = value_type const *; | |
using iterator = pointer; | |
using const_iterator = const_pointer; | |
using value_type = typename device_uvector<T>::value_type; | |
using reference = typename device_uvector<T>::reference; | |
using const_reference = typename device_uvector<T>::const_reference; | |
using pointer = typename device_uvector<T>::pointer; | |
using const_pointer = typename device_uvector<T>::const_pointer; |
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 had been thinking about whether it would be useful for device_scalar to provide begin()
and end()
...
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, thanks.
@gpucibot merge |
rapidsai/rmm#789 refactors `rmm::device_scalar`, which all of `cudf::scalar` depends on. Notably, it renames some methods, makes stream parameters explicit, and deletes streamless constructors. As a result, the present PR deletes the default and non-stream copy constructors of all the `cudf::*_scalar` classes. This should be merged immediately after rapidsai/rmm#789 because that PR will break the build. Authors: - Mark Harris (https://github.com/harrism) Approvers: - https://github.com/brandon-b-miller - Vukasin Milovanovic (https://github.com/vuule) - Robert (Bobby) Evans (https://github.com/revans2) - Robert Maynard (https://github.com/robertmaynard) URL: #8411
In comms/test.hpp `device_scalar::value` was not being passed an explicit stream, which means that the default stream was being synced. rapidsai/rmm#789 will remove the default from this parameter, and would have therefore broken the RAFT build. So this PR fixes the oversynchronization and ensures RAFT will build after the RMM PR is merged. Note this PR includes the cmake changes from #258 (just so I could build locally). Once #258 is merged this PR's changes will be simplified. Authors: - Mark Harris (https://github.com/harrism) Approvers: - Dante Gama Dessavre (https://github.com/dantegd) - Chuck Hastings (https://github.com/ChuckHastings) URL: #259
This PR refactors
device_scalar
to use a single-elementdevice_uvector
for its storage. This simplifies the implementation of device_scalar. Also changes the API ofdevice_scalar
so that its asynchronous / stream-ordered methods use the same API style (with explicit stream parameter) asdevice_uvector
anddevice_buffer
.Closes #570
This is a breaking change. When it is merged, PRs are likely to need to be merged immediately in other libraries to account for the API changes.
cudf::scalar
classes to changes inrmm::device_scalar
cudf#8411rmm::device_scalar
API cugraph#1637cuML(unused)cuSpatial(unused)