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

Add join method to DeviceBuffer #1035

Closed
wants to merge 1 commit into from

Conversation

jakirkham
Copy link
Member

Adds join method to DeviceBuffer analogous to bytes.join(...). Provides a simple way to concatenate buffers together into a single one.

@github-actions github-actions bot added the Python Related to RMM Python API label May 11, 2022
@jakirkham jakirkham added feature request New feature or request non-breaking Non-breaking change Python Related to RMM Python API and removed Python Related to RMM Python API labels May 11, 2022
@jakirkham jakirkham force-pushed the add_join branch 7 times, most recently from 2714e50 to 063f2da Compare May 11, 2022 23:40
@jakirkham jakirkham marked this pull request as ready for review May 12, 2022 01:51
@jakirkham jakirkham requested a review from a team as a code owner May 12, 2022 01:51
Comment on lines +309 to +310
cdef uintptr_t sp = <uintptr_t>self.c_data()
cdef size_t sdbs = self.c_size()
Copy link
Member

Choose a reason for hiding this comment

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

lots of very short and undescriptive variable names in this function.

Copy link
Contributor

Choose a reason for hiding this comment

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

Definitely could use clearer and more canonical names like sp->sep, sdbs->sep_bytes, etc.

Comment on lines +324 to +332
for i in range(N - 1):
db = L[i]
dp = <uintptr_t>db.c_data()
dbs = db.c_size()
copy_device_to_ptr(dp, rp + offset, dbs, stream)
offset += dbs
if sdbs > 0:
copy_device_to_ptr(sp, rp + offset, sdbs, stream)
offset += sdbs
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps a comment explaining this loop. The variable names don't help clarify it.

@shwina
Copy link
Contributor

shwina commented May 12, 2022

@jakirkham could you please provide a bit more context here? Is this to enable a specific feature or algorithm?

Comment on lines +333 to +336
db = L[N - 1]
dp = <uintptr_t>db.c_data()
dbs = db.c_size()
copy_device_to_ptr(dp, rp + offset, dbs, stream)
Copy link
Member

Choose a reason for hiding this comment

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

nit: can't we merge these lines into the loop?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, we would just need to change 330 from if sdbs > 0 to if sdbs > 0 and i != N-1 and update the for loop on 324 to use range(N).

@jakirkham
Copy link
Member Author

could you please provide a bit more context here? Is this to enable a specific feature or algorithm?

In Distributed serialization (part of spilling and communication), we often split and/or join frames as part of this process. ATM this just happens with host side serialization ("pickle" or "dask"). However we may want to extend this to CUDA-based serialization to allow for compression/decompression, consolidating many small frames into one larger one (like before sending), etc.

On the host side this is done with syntax like b"".join(...) or byte().join(...) or bytearray().join(...). Having support for similar syntax with DeviceBuffer would be handy as it would make easier to drop-in more places and leverage existing code paths in Distributed. Plus we can also be assured that the final result is a DeviceBuffer, which we are already use to working with in Dask serialization and RAPIDS will be familiar with as well.

This has also come up before primarily in issue ( rapidsai/cudf#9726 ). Though there is also overlap from ancillary issues ( rapidsai/ucx-py#478 ) ( rapidsai/dask-cuda#760 ).

Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

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

When I first read the description of this PR I was really expecting something more like a classmethod factory that just concatenated buffers together, I did not expect this to be a method using self as the separator for the purpose of concatenation. I see where the API is coming from though. It feels a little out of scope for RMM to me, but I also don't really see a better place for this feature to exist, so I'm OK with pushing forward if nobody else objects. The code needs some better variable naming/comments, but otherwise mostly looks fine.

Comment on lines +295 to +296
L : ``list`` of ``DeviceBuffer``s
stream : CUDA stream to use for copying, default the default stream
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
L : ``list`` of ``DeviceBuffer``s
stream : CUDA stream to use for copying, default the default stream
L : list
The ``DeviceBuffer``s to concatenate.
stream : Stream
The stream to use for copying. Defaults to the default stream

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we also name the parameter buffers instead?

@@ -285,6 +285,58 @@ cdef class DeviceBuffer:

return b

cpdef DeviceBuffer join(self, list L, Stream stream=DEFAULT_STREAM):
"""Joins a sequence of ``DeviceBuffer``s with ``self`` inbetween.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
"""Joins a sequence of ``DeviceBuffer``s with ``self`` inbetween.
"""Joins a sequence of ``DeviceBuffer``s with ``self`` in between.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this would be clearer if you actually copied more of the docstring from help(b''.join). Specifically, it's not obvious that "in between" means that self is inserted between every consecutive element. Use of the word "separator" to describe self might also help.

Comment on lines +309 to +310
cdef uintptr_t sp = <uintptr_t>self.c_data()
cdef size_t sdbs = self.c_size()
Copy link
Contributor

Choose a reason for hiding this comment

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

Definitely could use clearer and more canonical names like sp->sep, sdbs->sep_bytes, etc.

Comment on lines +333 to +336
db = L[N - 1]
dp = <uintptr_t>db.c_data()
dbs = db.c_size()
copy_device_to_ptr(dp, rp + offset, dbs, stream)
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, we would just need to change 330 from if sdbs > 0 to if sdbs > 0 and i != N-1 and update the for loop on 324 to use range(N).

cdef DeviceBuffer rdb = DeviceBuffer(size=s, stream=stream)
cdef uintptr_t rp = <uintptr_t>rdb.c_data()

cdef uintptr_t dp, offset = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

Why maintain an offset when you can just increment rp directly?

@jakirkham jakirkham changed the base branch from branch-22.06 to branch-22.08 May 20, 2022 07:19
@jakirkham
Copy link
Member Author

Moving to 22.08

@github-actions
Copy link

This PR has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this PR if it is no longer required. Otherwise, please respond with a comment indicating any updates. This PR will be labeled inactive-90d if there is no activity in the next 60 days.

@github-actions
Copy link

This PR has been labeled inactive-90d due to no recent activity in the past 90 days. Please close this PR if it is no longer required. Otherwise, please respond with a comment indicating any updates.

@harrism
Copy link
Member

harrism commented Sep 28, 2022

@jakirkham @shwina @vyasr so what do you think, is this out of scope for RMM? Is this PR dead?

@jakirkham
Copy link
Member Author

Going to close for now. Can reopen later as needed.

@jakirkham jakirkham closed this Sep 28, 2022
@jakirkham jakirkham deleted the add_join branch September 28, 2022 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request non-breaking Non-breaking change Python Related to RMM Python API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants