Primitive to support gathering one hop neighbors #2623
Conversation
… pointers with raft::device_span in edge_partition_view_t & edge_partition_device_view_t)
…efactor_count_local_edges
…efactor_count_local_edges
…id_intersection_op with std::is_invocable_v
seunghwak
added
feature request
…ce_v_frontier_outgoing_e_by_dst
…sult_t doesn't work properly with a device functor
seunghwak
changed the title
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## branch-22.10 #2623 +/- ##
===============================================
Coverage ? 60.07%
===============================================
Files ? 112
Lines ? 6154
Branches ? 0
===============================================
Hits ? 3697
Misses ? 2457
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. |
| @@ -0,0 +1,1039 @@ | |||
| /* | |||
| * Copyright (c) 2020-2022, NVIDIA CORPORATION. | |||
There was a problem hiding this comment.
Is this new (should be just 2022) or moved from somewhere?
There was a problem hiding this comment.
Copied from transfrom_reduce_v_frontier_outgoing_e_by_dst.cuh
| @@ -0,0 +1,104 @@ | |||
| /* | |||
| * Copyright (c) 2020-2022, NVIDIA CORPORATION. | |||
There was a problem hiding this comment.
Is this new (should be just 2022) or moved from somewhere?
There was a problem hiding this comment.
Yes, this is actually new. I will fix the copyright year.
|
@gpucibot merge |
transform_reduce_v_frontier_outgoing_e_by_dst(moved the first part of the implementation todetail/extract_transform_v_frontier_e, this moved code is used in the new primitive as well).extract_transform_v_frontier_outgoing_e@ChuckHastings To gather one hop neighbors, in SG, you need to call this primitive and an edge_op passed to the primitive should return src,dst, (edge weight), and (edge ID or type once we added edge property support). In MG, the result should be properly shuffled in addition. Then, call
thrust::sort_by_keyandthrust::reduce_by_keyto gather neighbors of each vertex together and compute degrees for each vertex. In SG, we might be able to avoidthrust::sort_by_keyif we change the primitive internals and provide some additional guarantees about the extracted output ordering, but I guess thisthrust::sort_by_keyoverhead is not too significant. Ifthrust::sort_by_keyin gathering one hop neighbors really becomes a performance bottleneck, we can re-visit this assumption.