Introducing MemoryType::PINNED_HOST#731
Conversation
28eafb0 to
f5a0173
Compare
f5a0173 to
dd74085
Compare
pentschev
left a comment
There was a problem hiding this comment.
Left only minor non-blocking questions, otherwise LGTM.
| return TableChunk(std::move(table), stream()); | ||
| } | ||
| case MemoryType::HOST: | ||
| case MemoryType::PINNED_HOST: |
There was a problem hiding this comment.
Should we implement an abstraction, or an type checker perhaps to use in such situations? E.g.:
is_host_memory(MemoryType type) {
switch (mem_type) {
case MemoryType::HOST:
case MemoryType::PINNED_HOST:
return true;
default:
return false;
}There was a problem hiding this comment.
Let's wait. In this case, I think we want to change behavior for PINNED_HOST: #726 (comment)
| HOST = 1, ///< Host memory | ||
| PINNED_HOST = 2 ///< Pinned host memory |
There was a problem hiding this comment.
shouldnt this be other way around? HOST = 2 and PINNED_HOST=1. Then they will match the indices of MEMORY_TYPES and MEMORY_TYPE_NAMES. Which could be important when someone static_casts the enum to size_t.
There was a problem hiding this comment.
The order that matters is in https://github.com/rapidsai/rapidsmpf/pull/731/files#diff-8284f273564b468de620841d4acdbc243fff0e68b5c0aae3dc13fbcbc10914b0R20-R22 and https://github.com/rapidsai/rapidsmpf/pull/731/files#diff-8284f273564b468de620841d4acdbc243fff0e68b5c0aae3dc13fbcbc10914b0R37-R39, it's just the enum here.
There was a problem hiding this comment.
Well, consider the following
auto m = MemoryType::PINNED_HOST;
auto m_to_s = MEMORY_TYPE_NAMES[static_cast<size_t>(m)]; // == "HOST" There was a problem hiding this comment.
The definition clearly bases itself off of MEMORY_TYPES and not MemoryType:
/// @brief Memory type names sorted to match `MEMORY_TYPES`.
constexpr std::array<char const*, MEMORY_TYPES.size()> MEMORY_TYPE_NAMES{
But I agree this is confusing, and I was going to say that one alternative could be to provide a function to get names, then I realized it already exists and in fact will hit the exact case you're pointing out.
Thus I agree, we either need to match the order or find a way to make this more robust providing an explicit separation of enums and the MEMORY_TYPES array providing the actual ordering.
There was a problem hiding this comment.
Good catch. It was indeed my intention to have MEMORY_TYPES define the order of preference.
For now, let’s also sort MemoryType: 7410e76.
In a follow-up we should introduce a proper class for arrays that can be indexed with MemoryType without using static_cast<std::size_t>, and that enforces the correct ordering.
7660997 to
7410e76
Compare
Co-authored-by: Lawrence Mitchell <wence@gmx.li>
|
Thanks everyone |
|
/merge |
No description provided.