-
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
Python API updates to enable explicit control of internal graph_t
creation and deletion
#2023
Python API updates to enable explicit control of internal graph_t
creation and deletion
#2023
Conversation
…t probably is not necessary given the dir name, updated @experimental decorator to not error on extension types (from cython), removed unnecessary gpu_graph_data class and replaced with cython SGGraph class.
…e callable, removed __init__.py file contents from connectivity in favor of just exposing functions in the top-level __init__.py.
…d an experimental/__init__.py file.
…y copies), added additional types for C API structs, added tests.
…2-initialexpertmode
Codecov Report
@@ Coverage Diff @@
## branch-22.02 #2023 +/- ##
================================================
+ Coverage 71.93% 72.87% +0.93%
================================================
Files 146 150 +4
Lines 9264 9669 +405
================================================
+ Hits 6664 7046 +382
- Misses 2600 2623 +23
Continue to review full report at Codecov.
|
… of cugraph_c with a leading underscore, moved test fixtures to conftest.py.
…2-initialexpertmode
…sociated expected outputs, more updates to pagerank function and test.
…e set correctly, fixed flake8 error.
…to branch-22.02-initialexpertmode
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.
A few minor observations. I think it's fine to go forward, but we probably should address these early in 22.04
c_api::cugraph_type_erased_device_array_t const* weights, | ||
c_api::cugraph_type_erased_device_array_view_t const* src, | ||
c_api::cugraph_type_erased_device_array_view_t const* dst, | ||
c_api::cugraph_type_erased_device_array_view_t const* weights, | ||
bool_t renumber, | ||
bool_t check, | ||
data_type_id_t edge_type) |
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, if we have 'edge_type', shouldn't there be 'vertex_type' 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.
Vertex_type is embedded in the type erased array. Edge type cannot be deduced from the other parameters.
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.
Approving (assuming FIXMEs will be addressed quickly in the next release).
@gpucibot merge |
…reation and deletion (rapidsai#2023) Python API updates to enable explicit control of internal `graph_t` creation and deletion. These changes will allow users who need more control over how the internal `graph_t` object is managed to have additional APIs to do so. Current cugraph algos construct the appropriate `graph_t` at the C++ boundary, run the algo, and destroy the object each time. This is more convenient and safer in some cases since it does not require the user to understand the necessary data format requirements for each algo (CSC, CSR, etc.), but it adds overhead to each algo call. If a user knows which algos will be called ahead of time and the relevant graph creation options to use, they can reuse the underlying `graph_t` object and eliminate the redundant creation/deletion expense. These APIs also allow for benchmarks to measure only the algo run time without the initial graph creation time. These changes are grouped into a category of enhancements sometimes referred to as "expert mode" Changes here include: * Updates to `pylibcugraph` to add the APIs from the `libcugraph_c` library for `graph_t` management and calling Pagerank and SSSP * Addition of the `experimental` namespace to `pylibcugraph`, which is where some of the new APIs will be until we finalize decisions on names, signatures, etc. * <s>Updates to cugraph Graph classes, Pagerank, and SSSP algos to call in to `pylibcugraph`</s> Authors: - Rick Ratzel (https://github.com/rlratzel) - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) Approvers: - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) - Brad Rees (https://github.com/BradReesWork) URL: rapidsai#2023
…reation and deletion (rapidsai#2023) Python API updates to enable explicit control of internal `graph_t` creation and deletion. These changes will allow users who need more control over how the internal `graph_t` object is managed to have additional APIs to do so. Current cugraph algos construct the appropriate `graph_t` at the C++ boundary, run the algo, and destroy the object each time. This is more convenient and safer in some cases since it does not require the user to understand the necessary data format requirements for each algo (CSC, CSR, etc.), but it adds overhead to each algo call. If a user knows which algos will be called ahead of time and the relevant graph creation options to use, they can reuse the underlying `graph_t` object and eliminate the redundant creation/deletion expense. These APIs also allow for benchmarks to measure only the algo run time without the initial graph creation time. These changes are grouped into a category of enhancements sometimes referred to as "expert mode" Changes here include: * Updates to `pylibcugraph` to add the APIs from the `libcugraph_c` library for `graph_t` management and calling Pagerank and SSSP * Addition of the `experimental` namespace to `pylibcugraph`, which is where some of the new APIs will be until we finalize decisions on names, signatures, etc. * <s>Updates to cugraph Graph classes, Pagerank, and SSSP algos to call in to `pylibcugraph`</s> Authors: - Rick Ratzel (https://github.com/rlratzel) - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) Approvers: - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) - Brad Rees (https://github.com/BradReesWork) URL: rapidsai#2023
…reation and deletion (rapidsai#2023) Python API updates to enable explicit control of internal `graph_t` creation and deletion. These changes will allow users who need more control over how the internal `graph_t` object is managed to have additional APIs to do so. Current cugraph algos construct the appropriate `graph_t` at the C++ boundary, run the algo, and destroy the object each time. This is more convenient and safer in some cases since it does not require the user to understand the necessary data format requirements for each algo (CSC, CSR, etc.), but it adds overhead to each algo call. If a user knows which algos will be called ahead of time and the relevant graph creation options to use, they can reuse the underlying `graph_t` object and eliminate the redundant creation/deletion expense. These APIs also allow for benchmarks to measure only the algo run time without the initial graph creation time. These changes are grouped into a category of enhancements sometimes referred to as "expert mode" Changes here include: * Updates to `pylibcugraph` to add the APIs from the `libcugraph_c` library for `graph_t` management and calling Pagerank and SSSP * Addition of the `experimental` namespace to `pylibcugraph`, which is where some of the new APIs will be until we finalize decisions on names, signatures, etc. * <s>Updates to cugraph Graph classes, Pagerank, and SSSP algos to call in to `pylibcugraph`</s> Authors: - Rick Ratzel (https://github.com/rlratzel) - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) Approvers: - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) - Brad Rees (https://github.com/BradReesWork) URL: rapidsai#2023
…reation and deletion (rapidsai#2023) Python API updates to enable explicit control of internal `graph_t` creation and deletion. These changes will allow users who need more control over how the internal `graph_t` object is managed to have additional APIs to do so. Current cugraph algos construct the appropriate `graph_t` at the C++ boundary, run the algo, and destroy the object each time. This is more convenient and safer in some cases since it does not require the user to understand the necessary data format requirements for each algo (CSC, CSR, etc.), but it adds overhead to each algo call. If a user knows which algos will be called ahead of time and the relevant graph creation options to use, they can reuse the underlying `graph_t` object and eliminate the redundant creation/deletion expense. These APIs also allow for benchmarks to measure only the algo run time without the initial graph creation time. These changes are grouped into a category of enhancements sometimes referred to as "expert mode" Changes here include: * Updates to `pylibcugraph` to add the APIs from the `libcugraph_c` library for `graph_t` management and calling Pagerank and SSSP * Addition of the `experimental` namespace to `pylibcugraph`, which is where some of the new APIs will be until we finalize decisions on names, signatures, etc. * <s>Updates to cugraph Graph classes, Pagerank, and SSSP algos to call in to `pylibcugraph`</s> Authors: - Rick Ratzel (https://github.com/rlratzel) - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) Approvers: - Chuck Hastings (https://github.com/ChuckHastings) - Seunghwa Kang (https://github.com/seunghwak) - Brad Rees (https://github.com/BradReesWork) URL: rapidsai#2023
Python API updates to enable explicit control of internal
graph_t
creation and deletion. These changes will allow users who need more control over how the internalgraph_t
object is managed to have additional APIs to do so. Current cugraph algos construct the appropriategraph_t
at the C++ boundary, run the algo, and destroy the object each time. This is more convenient and safer in some cases since it does not require the user to understand the necessary data format requirements for each algo (CSC, CSR, etc.), but it adds overhead to each algo call. If a user knows which algos will be called ahead of time and the relevant graph creation options to use, they can reuse the underlyinggraph_t
object and eliminate the redundant creation/deletion expense. These APIs also allow for benchmarks to measure only the algo run time without the initial graph creation time.These changes are grouped into a category of enhancements sometimes referred to as "expert mode"
Changes here include:
pylibcugraph
to add the APIs from thelibcugraph_c
library forgraph_t
management and calling Pagerank and SSSPexperimental
namespace topylibcugraph
, which is where some of the new APIs will be until we finalize decisions on names, signatures, etc.Updates to cugraph Graph classes, Pagerank, and SSSP algos to call in topylibcugraph