Improved condense hierarchy of HDBSCAN #7459
Conversation
jinsolp
added
non-breaking
jinsolp
changed the title
|
It seems like the number of omp threads affect the performance, but the time doesn't always scale linearly. I believe it depends on what the tree looks like. I think the number of persistent nodes might matter, because if there are more persistent nodes, each thread is more likely to climb "less levels" of the tree (because it climbs until it runs into a persistent node). |
|
Heuristics are determined after investigating that the persistent/internal node ratio does affect the perf of this CPU implementation 
|
csadorf
left a comment
csadorf
left a comment
There was a problem hiding this comment.
Review is not yet complete, but here is a first set of comments.
cpp/src/hdbscan/detail/condense.cuh
Outdated
|
|
||
| /* Heuristic dispatching to CPU. A high persistent_ratio means there are more chances to stop early | ||
| as we climb up the tree, making it more efficient for bottom-up CPU approach*/ | ||
| bool dispatch_to_cpu(int num_persistent, int n_leaves) |
There was a problem hiding this comment.
I think there is a very good chance that after we introduce this change, all of our testing either dispatches to CPU or does not dispatch to CPU. We need to ensure that we have a variety of test conditions such that both paths are hit.
cpp/src/hdbscan/detail/condense.cuh
Outdated
| if (persistent_ratio >= 0.001) { | ||
| return true; | ||
| } else if (persistent_ratio >= 0.0001 && num_omp_threads >= 16) { | ||
| return true; | ||
| } else if (num_omp_threads >= 64) { | ||
| return true; | ||
| } else { | ||
| return false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Should this heuristic really be independent of data set size?
There was a problem hiding this comment.
This is independent of dataset size because it's branching based on the ratio, not the absolute number
There was a problem hiding this comment.
My point is that I suspect that this heuristic should take dataset size into account. That's something we should at least evaluate.
|
Changing target branch to main to target 26.02 |
jinsolp
force-pushed
the
opt-condense-hierarchy
branch
from
78ce1b0 to
d914709
Compare
github-actions
bot
added
conda
jinsolp
force-pushed
the
opt-condense-hierarchy
branch
from
d914709 to
1ce68a4
Compare
github-actions
bot
removed
conda
jinsolp
force-pushed
the
opt-condense-hierarchy
branch
from
1ce68a4 to
409acf0
Compare
|
force pushed because of issues while rebasing to the main branch |
3 participants
Closes #7377
This PR optimizes the
build_condensed_hierarchyof HDBSCAN.Our previous implementation runs a top-down bfs tree traversal, where the GPU kernel is launched for every level of the tree. This is very slow because the tree is not balanced.
This PR introduces a bottom-up approach by pointer-chasing up to the parent on the CPU using omp threads.
This is much faster without any accuracy loss in the final result.
Table below shows two main parts of our HDBSCAN implementation (build linkage, and condense).
adjusted_rand_scoreis computed against our implementation using brute force graph build + original GPU condense implementation.BF + orig : Brute force MR graph build + original top-down GPU condense
NND + orig: nn-descent MR graph build + original top-down GPU condense
BF + new: Brute force MR graph build + new bottom-up CPU condense in this PR
NND + new: nn-descent MR graph build + new bottom-up CPU condense in this PR