From 262e52f192844605a7237d9394cfcda05d636e6e Mon Sep 17 00:00:00 2001 From: "Richard (Rick) Zamora" Date: Tue, 10 Sep 2024 16:51:46 -0500 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Peter Andreas Entschev --- docs/source/examples/best-practices.rst | 2 +- docs/source/spilling.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/examples/best-practices.rst b/docs/source/examples/best-practices.rst index a61b40e7..d6cc7189 100644 --- a/docs/source/examples/best-practices.rst +++ b/docs/source/examples/best-practices.rst @@ -47,7 +47,7 @@ Additionally, when using `Accelerated Networking`_ , we only need to register a Spilling from Device ~~~~~~~~~~~~~~~~~~~~ -Dask CUDA offers several different ways to enable automatic spilling from device memory. +Dask-CUDA offers several different ways to enable automatic spilling from device memory. The best method often depends on the specific workflow. For classic ETL workloads with `Dask cuDF `_, cuDF spilling is usually the best place to start. See `spilling`_ for more details. diff --git a/docs/source/spilling.rst b/docs/source/spilling.rst index 1087f4a2..066284fa 100644 --- a/docs/source/spilling.rst +++ b/docs/source/spilling.rst @@ -169,4 +169,4 @@ Although cuDF spilling is the best option for most Dask cuDF ETL workflows, it will be much less effective if that workflow converts between ``cudf.DataFrame`` and other data formats (e.g. ``cupy.ndarray``). Once the underlying device buffers are "exposed" to external memory references, they become "unspillable" by cuDF. -In cases like this (e.g. Dask CUDA + XGBoost), JIT-Unspill is usually a better choice. +In cases like this (e.g., Dask-CUDA + XGBoost), JIT-Unspill is usually a better choice.