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.

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

Skip dispatching to GPU for unimplemented metrics in UMAP #6224

Open
wants to merge 4 commits into
base: branch-25.02
Choose a base branch
from

Conversation

betatim
Copy link
Member

@betatim betatim commented Jan 14, 2025

This lists more metrics that the CPU umap library supports but cuml doesn't yet support. By listing them as not implemented we don't dispatch to the GPU when a user selects them.

Also added them to a test to check that they do not raise an error. It would be nice to check that they ran on the CPU when the accelerator is enabled, but I couldn't find a nice way to do it :-/ Ideas welcome.

@betatim betatim requested a review from a team as a code owner January 14, 2025 16:16
@betatim betatim requested review from teju85 and divyegala January 14, 2025 16:16
@github-actions github-actions bot added the Cython / Python Cython or Python issue label Jan 14, 2025
…ms/test_accel_umap.py

Co-authored-by: Dante Gama Dessavre <[email protected]>
@betatim betatim added the non-breaking Non-breaking change label Jan 15, 2025
@betatim
Copy link
Member Author

betatim commented Jan 15, 2025

I feel like I am missing something. The tests are still failing with FAILED estimators_hyperparams/test_accel_umap.py::test_umap_metric[russelrao] - ValueError: metric is neither callable nor a recognised string - but russelrao is how the metric is spelt??

@betatim
Copy link
Member Author

betatim commented Jan 15, 2025

The answer is that the docs call it russelrao but the code actually looks for russellrao.

@betatim betatim changed the title Skip dispatching to GPU for unimplemented metrics Skip dispatching to GPU for unimplemented metrics in UMAP Jan 15, 2025
@betatim betatim requested a review from a team as a code owner January 15, 2025 16:14
@betatim betatim requested a review from jameslamb January 15, 2025 16:14
@github-actions github-actions bot added the ci label Jan 15, 2025
@betatim betatim force-pushed the blacklist-unsupported-metrics branch from df524b9 to 18dc640 Compare January 16, 2025 09:09
Copy link
Member

@jameslamb jameslamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend reverting that rapids-mamba-retry --quiet. I've explained the tradeoffs in a comment.

Marking this "approve" so you're not blocked waiting on ci-codeowners, and so you can merge it without further review if you all want to make a different choice than I would in the face of those tradeoffs.

@@ -17,7 +17,7 @@ rapids-dependency-file-generator \
--prepend-channel "${CPP_CHANNEL}" \
--prepend-channel "${PYTHON_CHANNEL}" | tee env.yaml

rapids-mamba-retry env create --yes -f env.yaml -n test
rapids-mamba-retry env create --quiet --yes -f env.yaml -n test
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the goal of adding this --quiet?

For context... we'd recently tried to do that globally in CI images for RAPIDS, but found that it seemed to have the side effect of suppressing exception names from mamba, making rapids-mamba-retry ineffective:

rapidsai/ci-imgs#220

rapids-mamba-retry / rapids-conda-retry work by string-matching on Python exceptions:

https://github.com/rapidsai/gha-tools/blob/0558ffce255e4e7da5d5312e79f35dd81e444144/tools/rapids-conda-retry#L82

So adding --quiet here might mean you're trading quieter logs for more need to manually retry failures from conda.

Copy link
Member Author

@betatim betatim Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly added it here to reduce the number of lines I have to scroll past to see the output from the pytest command. It is somewhat annoying that the progress bars seem to take up many many many many lines :-/ but yeah, not really interested in negotiating with the rest of RAPIDS about this change (I'll revert it when I'm done with this PR) :D

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to reduce the number of lines I have to scroll past to see the output from the pytest command

I agree, it's annoying :/

That's why we'd attempted to make quiet: true the global setting for RAPIDS CI: rapidsai/ci-imgs#217

But breaking the retry mechanism was just not worth it... I think having to scroll past some logs lines is better than having to manually re-run CI.

Anyway, the work to actually find the root cause of these excessive empty lines is still something we should do. Put up rapidsai/ci-imgs#228 to track that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed that it is something we'd have to fix in conda/mamba? Somehow making it aware of the fact that no human is watching so that it can either not output a progress bar or some such. At least it seems like there are CLI tools out there that somehow adjust the fancyness of their output. Alas, I have no idea how they do it :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, it might also be a side effect of the RAPIDS-specific wrappers we have around those tools. Put up one idea at rapidsai/ci-imgs#228 (comment)

Anyway, that ci-imgs issue is a good tracking issue for this. Hopefully we can get more specific reproducible examples and make some progress there. I'll try to look into it when I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Cython / Python Cython or Python issue non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants