-
Notifications
You must be signed in to change notification settings - Fork 310
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
Multi-GPU induced subgraph tests code #2602
Multi-GPU induced subgraph tests code #2602
Conversation
rerun tests |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## branch-22.12 #2602 +/- ##
===============================================
Coverage ? 60.44%
===============================================
Files ? 111
Lines ? 6515
Branches ? 0
===============================================
Hits ? 3938
Misses ? 2577
Partials ? 0 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
rerun tests |
* num_subgraphs]). The elements of @p subgraph_vertices for each subgraph should be sorted in | ||
* ascending order and unique. | ||
* @param num_subgraphs Number of induced subgraphs to extract. | ||
* @param subgraph_offsets Span pointing to subgraph vertex offsets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we better be little more specific here?
Maybe add something like the following.
@p subgraph_offsets and @p subgraph_vertices provide vertex sets (or local vertex sets in multi-GPU) for @p subgraph_offsets.size() - 1 subgraphs to extract.
For the i'th subgraph to extract, one can extract the (local-)vertex set by accessing a subset of @p subgraph_vertices, where the range of the subset is [@p subgraph_offsetes[i], @p subgraph_offsets[i + 1]).
In multi-GPU, the vertex set for each subgraph is distributed in multiple-GPUs and each GPU holds only the vertices that are local to the GPU.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the suggested text.
[subgraph_offsets, subgraph_vertices, num_subgraphs, edge_partition] __device__(auto i) { | ||
[subgraph_offsets, | ||
subgraph_vertices, | ||
num_subgraphs = subgraph_offsets.size() - 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like num_subgraphs
is not used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed
@@ -206,7 +208,7 @@ extract_induced_subgraphs( | |||
thrust::make_counting_iterator(num_aggregate_subgraph_vertices), | |||
[subgraph_offsets, | |||
subgraph_vertices, | |||
num_subgraphs, | |||
num_subgraphs = subgraph_offsets.size() - 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like num_subgraphs
is not used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed
hr_clock.start(); | ||
} | ||
|
||
// FIXME: turn-off do_expensive_check once verified. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this code is now verified, so we can turn-off expensive check and delete this FIXME.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turned off
h_cugraph_subgraph_edgelist_majors, | ||
h_cugraph_subgraph_edgelist_minors, | ||
h_cugraph_subgraph_edgelist_weights, | ||
h_cugraph_subgraph_edge_offsets); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, we typically compare the SG result with the MG result in multi-GPU testing (and compare with the reference code output in SG testing). If I am not mistaken, here, we are comparing with the reference code output in MG as well. Any motivation for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too lazy to write two different comparison functions :-)
It felt like better code reuse just to validate against the reference implementation rather than write a second independent test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the initial motivation is that, we may run with larger data on MG, and comparing with the SG result will allow testing with bigger data than a sequential reference implementation. When I test something on multi-GPUs, I sometimes override the rmat_scale to the largest that fit within a single GPU to validate the MG results against the SG.
Do you want to move away from this convention (and do the same for other tests as well) or may compare with the reference just for induced subgraph?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is not something that I have been doing when testing MG, but I can see the value in that. I will look at recasting this test to compare against SG.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest push has refactored this.
…eference implementation
template <typename vertex_t, typename edge_t, typename weight_t, bool store_transposed> | ||
std::tuple<cugraph::graph_t<vertex_t, edge_t, weight_t, store_transposed, false>, | ||
std::optional<rmm::device_uvector<vertex_t>>> | ||
mg_graph_to_sg_graph( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a better mechanism than reading/creating a separate SG graph as we have been doing elsewhere (For tests with R-mat graphs, we rely on the fact that our pseduo random number generator is deterministic for a given seed, but we no longer need to rely on this).
Not a high priority thing, but we may better apply this mechanism in all the other MG C++ tests as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking this when I created it. Once we merge this PR I'll add an issue to the backlog to update the other tests.
rerun tests |
@gpucibot merge |
Define MG tests for induced subgraph. The test won't work until implementation is complete, which will be in a later PR. C API definition and C API tests will also be in a later PR.
Marked as breaking as the C++ API changes.
Closes #2531
Closes #2534