Define and implement C/C++ for MNMG Egonet #2864
Conversation
…s directly usable since it's already based on graph_t
ChuckHastings
added
2 - In Progress
improvement
|
rerun tests |
ChuckHastings
changed the title
| @@ -1380,6 +1384,37 @@ extract_ego(raft::handle_t const& handle, | |||
| vertex_t n_subgraphs, | |||
| vertex_t radius); | |||
|
|
|||
| /** | |||
| * @brief returns induced EgoNet subgraph(s) of neighbors centered at nodes in source_vertex within | |||
| * a given radius. | |||
There was a problem hiding this comment.
Isn't this identical to k-hop neighbors?
There was a problem hiding this comment.
Umm... maybe not... I assume identical only when k=1.
There was a problem hiding this comment.
Essentially the ego net for a vertex v1 and a radius of k is the following:
- compute the distance of every vertex in the graph from v1
- induce subgraph for the subset of vertices that are of distance <= k
So for radius = 1, that will include v1, all of its neighbors, the edges to its neighbors and the edges between its neighbors.
For radius = 2, that will include v1, all of its neighbors, all of its 2-hop neighbors, the edges to the 1-hop neighbors, the edges between the 1-hop neighbors, the edges from the 1-hop neighbors to the 2-hop neighbors and the edges between the 2-hop neighbors.
etc.
There was a problem hiding this comment.
Gotcha, yeah... so this is basically finding [0, radius]-hop neighbors then running induced subgraph, so this can be a bit different from just running radius-hop neighbors then running induced subgraph.
| 1, | ||
| direction_optimizing, | ||
| radius, | ||
| do_expensive_check); |
There was a problem hiding this comment.
Maybe just add a FIXME and address later, but this looks very inefficient (but not less efficient than what we had... so better kick out cython.cu first).
Sequentially running one BFS (with maximum distance of radius) per source vertex can largely under-utilize a GPU (or multiple GPUs in multi-GPU runs).
We may better either run multi-source BFS, or run 1-hop neighbors recursively (radius times).
There was a problem hiding this comment.
There is a FIXME on line 93 (about 20 lines higher) observing that this is likely slow. Is that sufficient to address this concern?
There was a problem hiding this comment.
I saw that FIXME but wasn't sure about the until the frontiers are large enough to use this approach part. But we can defer this discussion to the future.
The reason I wasn't sure about the FIXME comment.
I think we'd better not use this approach (i.e. running single source BFS in a sequential loop). Running 1-hop neighbors recursively sounds like a simpler approach with optimal parallelism but we may revisit this in the future when we actually update this algorithm.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## branch-22.12 #2864 +/- ##
===============================================
Coverage ? 60.72%
===============================================
Files ? 122
Lines ? 6880
Branches ? 0
===============================================
Hits ? 4178
Misses ? 2702
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. |
|
@gpucibot merge |
Define and implement C API for egonet. This will help us eliminate dependence on
cython.cu.Closes #2906
Closes #2907
Closes #2908
Closes #2909
Closes #2910
Closes #2911