-
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
deep_copy
of View
of non-trivially copyable type leads to byte-wise copy
#6986
Comments
See #2021. |
Basically we are in somewhat of a bind here. In order to move across memory-space boundaries we may have no option other than to men-cpy but trivially-copyable is too harsh a condition. This is the same issue for which SYCL introduced its device copyable trait you can opt in too. Maybe we should consider doing this for Kokkos 5, i.e. require it. For now I don't want to guarantee different semantic behavior depending on the memory spaces you copy between. So effectively mem-cpy it is. We should document this properly though. There are other similar thorny issues. For example the functors we use must be "device copyable" because we effectively have to move them to some place on the GPU. That move is NOT done via a copy constructor. Furthermore that object is not destructed either. And while I get the desire to treat this rigorously: practically no one has complained about it in 12 years of Kokkos deployment - and fixing it properly means a bunch of extra boilerplate everyone has to write or significant performance costs. Here is a sketch for a fix:
All in all I would expect 10%-30% percent slow down for apps which don't do the proper opt-in based on what some of these mechanism cost (e.g. the large functor launch mechanism) and the extra cost in latency. |
Kokkos currently implements the
deep_copy
of aView
as a byte-wise copy under conditions summarized in this comment:kokkos/core/src/Kokkos_CopyViews.hpp
Lines 1758 to 1759 in d88e2a5
These conditions are made rigorous in the code that follows in
Kokkos_CopyViews.hpp
by using type traits.It is notable that these conditions do not guard for the value type of the
View
to be trivially copyable. This current behavior ofdeep_copy
for non-trivially copyable value types may be surprising. Especially between assignable memory spaces, it may be expected that the copy constructor/copy assignment operator is called.The behavior of
std::copy
is different. It carries out the copy as a byte-wise copy only for trivially copyable value types.If this current behavior is not intended, a solution may consist of leading the case of non-trivially copyable value types to an implementation that uses the
ViewCopy
functor:kokkos/core/src/Kokkos_CopyViews.hpp
Lines 272 to 292 in c6d8647
We have tested this behavior by using a helper class that we can make non trivially copyable and that can count the number of times its special functions are called:
The code of the helper class, called
tester_t
in the snippet, is in attachment:Joint work with @romintomasetti. Issue created after a brief discussion with @dalg24.
The text was updated successfully, but these errors were encountered: