Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[BUG] Python tests take too long #83

Closed
afender opened this issue Feb 19, 2019 · 3 comments
Closed

[BUG] Python tests take too long #83

afender opened this issue Feb 19, 2019 · 3 comments
Assignees
@jwyles
Labels
bug Something isn't working

Comments

@afender
Copy link
Member

afender commented Feb 19, 2019

Python tests take more than 30 min to run. This is blocking the testing platform for too long. Users may also think that something is not working correctly.

We should identify what takes so long (afaik, most of the time is spent in NextworkX to get the reference result) and try to reduce the total time as much as possible.
@afender afender added bug Something isn't working 1 - On Deck labels Feb 19, 2019
@seunghwak seunghwak mentioned this issue Feb 19, 2019
Closed
@dantegd
Copy link
Member

dantegd commented Feb 19, 2019

If reducing the problem sizes for speeding up networkx is not an option, why not precompute the expected results and then compare to this saved results to skip networkx long processing time?

@afender
Copy link
Member Author

afender commented Feb 19, 2019

The problem sizes look quite small already but we can consider reducing it further. As long as it is large enough to run on multiple SMs that's good enough.

I agree that, for tests where Nx will be identified as the bottleneck, we can generate and save some golden data. We already do that for several internal C++ tests actually.

@jwyles
Copy link
Contributor

jwyles commented Feb 20, 2019

Please assign this to me. I am going to start working on it.
Plan: Swap out dblp.mtx with a smaller (but large enough to be on multiple SM) matrix in the tests. This will reduce the NetworkX overhead to a reasonable amount. Have all tests that compare series first copy data from the GPU to a numpy array for faster compares.

@jwyles jwyles mentioned this issue Feb 20, 2019
Closed
@afender afender mentioned this issue Feb 25, 2019
Merged
@jwyles jwyles mentioned this issue Feb 26, 2019
Merged
@BradReesWork BradReesWork reopened this Feb 26, 2019
ChuckHastings pushed a commit to ChuckHastings/cugraph that referenced this issue Jun 14, 2021
@dantegd
Update to CMake 3.20 features, rapids-cmake and CPM (rapidsai#187)
fe5f40a 
PR updates RAFT's CMake and uses CPM for dependency management. Still WIP, meant for early 0.20, but opening the PR to start debugging in CI. 

This is heavily based on cuDF's, RMM's and cumlprims' changes. PR does the following:

- [x] Adopt CPM:
    - [x] RMM
    - [x] FAISS
    - [x] GTest
    - [ ] NCCL: Missing building from source, will be added if/when required
    - [ ] UCX: Missing building from source, will be added if/when required
    - [x] CUB for CUDA < 11.0
- [x] Update arch detection 
- [x] Use generators to allow clang compilation as well
- [x] Updates to outdated cmake parts and remove old code
- [x] Update code to aid transition to rapidsai#83

Authors:
  - Dante Gama Dessavre (https://github.com/dantegd)
  - Robert Maynard (https://github.com/robertmaynard)

Approvers:
  - Robert Maynard (https://github.com/robertmaynard)
  - Rick Ratzel (https://github.com/rlratzel)
  - Divye Gala (https://github.com/divyegala)

URL: rapidsai/raft#187
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jwyles jwyles

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dantegd @BradReesWork @jwyles @afender