Execution device interoperability documentation

[viclafargue]

No description provided.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[wphicks]

Looks good! Nice and concise. Had a few suggestions for the text, but the code looks good. I'd also be interested in any feedback from @beckernick if you have a moment to glance at this?

[beckernick]

This looks great overall. Left two small comments on the notebook.

I think the small README update is the right choice until we add support for a few more operators and graduate device selection out of experimental. At that point, we can do a broader update.

I think we should update the documentation with a device selection support matrix and update operator docstrings to indicate whether the operator supports device selection. I will separate issues for those and can take them on.

[beckernick]

The implication of this notebook is that it's possible (for all models) to:

1. Train an estimator on the GPU and save it
2. Reconstruct and user the estimator on a CPU-only system

Does this work for all models or only GLMs at the moment? I had thought the latter, and if so we may want to tweak the framing here to focus on the non-deployment scenario.

[viclafargue]

You are right. Some of the models implement pickling and CPU/GPU interoperability but lack the CPU-to-GPU feature at the moment (i.e.: UMAP and HDBSCAN). Most models with serialization to disk + CPU/GPU interop should allow the deployment scenario though. Sure, I will modify the notebook so that it focuses a bit more on the non-deployment scenario and will also specify in the markdown that some of the models do not implement the CPU-to-GPU feature.

[codecov-commenter]

Codecov Report

Base: 67.11% // Head: 67.20% // Increases project coverage by +0.08% 🎉

Coverage data is based on head (f3d4900) compared to base (85b33df).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files

@@               Coverage Diff                @@
##           branch-23.02    #5130      +/-   ##
================================================
+ Coverage         67.11%   67.20%   +0.08%     
================================================
  Files               192      192              
  Lines             12396    12372      -24     
================================================
- Hits               8320     8315       -5     
+ Misses             4076     4057      -19     

Impacted Files	Coverage Δ
python/cuml/common/device_selection.py	93.33% <50.00%> (-6.67%)	⬇️
python/cuml/dask/common/input_utils.py	34.37% <0.00%> (-1.51%)	⬇️
python/cuml/dask/ensemble/randomforestregressor.py	33.87% <0.00%> (-1.05%)	⬇️
...ython/cuml/dask/ensemble/randomforestclassifier.py	29.88% <0.00%> (-0.80%)	⬇️
python/cuml/preprocessing/TargetEncoder.py	85.22% <0.00%> (-0.08%)	⬇️
...on/cuml/benchmark/automated/bench_random_forest.py	0.00% <0.00%> (ø)
python/cuml/dask/preprocessing/label.py	40.00% <0.00%> (+0.71%)	⬆️
...ython/cuml/dask/neighbors/kneighbors_classifier.py	23.42% <0.00%> (+1.57%)	⬆️
python/cuml/dask/neighbors/nearest_neighbors.py	28.75% <0.00%> (+2.00%)	⬆️
python/cuml/dask/neighbors/kneighbors_regressor.py	32.75% <0.00%> (+2.11%)	⬆️

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

[csadorf]

Is the reason for naming this function get_current_device_type() as opposed to get_global_device_type(), because the device type could be temporarily changed? If not, I would probably recommend to use a symmetric naming scheme here. Tagging @wphicks since I think you proposed the name in the first place.

[viclafargue]

Thanks for noticing this. Just corrected it.

[dantegd]

/merge