Fix UMAP issues with large inputs #6245
Conversation
There was a problem hiding this comment.
Looking good! Let's just make sure to IWYU for the new uses of uint64_t. Using C++ types (std::uint64_t) in our non-CUDA code would be a bonus, but it shouldn't block merge. I've also called out some spots where we could use uniform initialization syntax rather than a bare cast.
|
@viclafargue That last commit was unsigned. Could you sign it and push that up? |
There was a problem hiding this comment.
@viclafargue and I discussed this briefly last week, but given the nature of the 64-bit hardcoded changes here, I would like to see at least a small benchmark before this is merged so that we can feel comfortable that this doesn’t have a huge impact on the runtime.
github-actions
bot
removed
conda
|
/ok to test |
|
/ok to test |
|
This benchmark was ran a while back just before the last changes. It demonstrate that there does not seem to be a performance drop when switching to |
|
/ok to test |
|
/ok to test |
|
/ok to test |
There was a problem hiding this comment.
Approving for now, but can you please create an issue to follow up on the hardcodings of uint64_t in umap.cu? It would be nice for us to figure a good strategy to determine whether or not we should be using uint64_t or int based on the dataset size, rasther than hardcoding everywhere. cc @dantegd
|
/merge |
|
Here is the issue #6310 |
Answers #6204