-
Notifications
You must be signed in to change notification settings - Fork 304
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
Fea renumbering test #1742
Fea renumbering test #1742
Conversation
dst_v.size(), | ||
renumber_map_labels_v.data(), | ||
0, | ||
static_cast<vertex_t>(renumber_map_labels_v.size())); |
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.
This doesn't matter in SG, but if we consider MG extension, unrenumber_local_int_vertices
works only with vertices in the range of [graph_view.get_local_vertex_first(), graph_view.get_local_vertex_last())
; so unrenumber_int_vertices (https://github.com/rapidsai/cugraph/blob/branch-21.10/cpp/include/cugraph/experimental/graph_functions.hpp#L212) could be more extensible.
Also note the comment in https://github.com/rapidsai/cugraph/blob/branch-21.10/cpp/include/cugraph/experimental/graph_functions.hpp#L185. If we need to unrenumber local edges in the performance critical path, we need to add addition unrenumber functions for better performance.
cpp/tests/utilities/test_graphs.hpp
Outdated
// TODO: Tease through generate_graph_from_rmat_params | ||
// to extract the edgelist part | ||
// Call cugraph::translate_vertex_ids(handle, d_src_v, d_dst_v, base_vertex_id_); | ||
constexpr bool symmetric{true}; |
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.
Do we always symmetrize R-mat graphs? This is necessary for WCC or Louvain, but there are many other algorithms that work with asymmetric R-mat graphs.
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.
Do we always symmetrize R-mat graphs? This is necessary for WCC or Louvain, but there are many other algorithms that work with asymmetric R-mat graphs.
@ChuckHastings I'm waiting for your answer for this to approve this PR.
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 was the intention of my FIXME comment. Right now the symmetrization flag is inside the test graph classes. I think the goal would be to set the symmetrization flag to false for all of the test graph classes (except file which would read it from the MM file and return the intended value) and add a test graph wrapper that will symmetrize any test graph so that Louvain and WCC could use that wrapper around rmat and other generators.
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.
Where is the FIXME comment?
Rmat_Usecase
has private member variable bool undirected_{};
So, this should be used instead of redefining symmetric
here and ignoring the member variable. I assume users will be surprised if they set Rmat_Usecase.undirected_ = false and get symmetric graphs.
And it seems like construct_graph
is still calling
return generate_graph_from_rmat_params<vertex_t, edge_t, weight_t, store_transposed, multi_gpu>(
handle,
scale_,
edge_factor_,
a_,
b_,
c_,
seed_,
undirected_,
scramble_vertex_ids_,
test_weighted,
renumber,
partition_ids,
comm_size);
So, construct_edgelist
here is actually unused. Are you planning to replace generate_graph_from_rmat_params
but haven't done the job, yet? Why not replace in this PR if it's the intention?
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.
The original implementation work here was truncated and a partially implemented capability was pushed many months ago. This is unfinished tech debt. I will look into making that change as part of this PR.
rerun tests |
1 similar comment
rerun tests |
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.
Looks good to me except for few minor complaints.
// do the perf measurements | ||
// enabled by command line parameter s'--perf' | ||
// | ||
static int PERF = 0; |
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.
We're no longer using PERF, this gets replaced with cugraph::test::g_perf
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's what happens when you start something and then set it aside :-)
Fixed in next push.
} | ||
|
||
if (PERF) { | ||
handle.get_stream_view().synchronize(); // for consistent performance measurement |
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're using CUDA_TRY(cudaDeviceSynchronize()) elsewhere.
This will be lower overhead and proper if every operation is executed on stream
(this should be true... but may not be always true...) but we may better not mix the two in our tests. So, do you think we'd better use stream synchronize in our tests or we'd better continue using cudaDeviceSynchronize?
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 switched to CUDA_TRY(cudaDeviceSynchronize())
in the next push.
I'm not particularly concerned about overhead in tests. We can consider that change as a general possibility later.
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.
Yeah... me, neither. Just wasn't happy about mixing cudaDeviceSynchronize() and stream_view.synchronize(). Either is fine for me as long as we're consistent.
::testing::Values(cugraph::test::Rmat_Usecase(10, 16, 0.57, 0.19, 0.19, 0, false, false)))); | ||
|
||
INSTANTIATE_TEST_SUITE_P( | ||
rmat_large_tests, |
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.
See https://github.com/rapidsai/cugraph/blob/branch-21.10/cpp/tests/prims/mg_count_if_v.cu#L225
We renamed rmat_large_tests to rmat_benchmark_test to use this in C++ benchmarking.
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.
Addressed in latest push.
rerun tests |
@gpucibot merge |
Adds a C++ renumbering test for integer column renumbering.
Also refactored some of the test utilities (some tech debt from the original development of the test utilities). Test graph construction now relies upon the edgelist construction calls instead of replicating functionality.