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

Improve config handling in cpp and python #644

Merged
merged 21 commits into from
Mar 3, 2025

Conversation

kingcrimsontianyu
Copy link
Contributor

@kingcrimsontianyu kingcrimsontianyu commented Feb 24, 2025

Closes #642
Closes #526

This PR makes the following changes:

Improve config setter/getter

This PR lets the properties in kvikio.defaults and kvikio.cufile_driver be set using a friendly Pythonic interface (C++ interface has also been adjusted for improved clarity). The expression below can appear standalone which sets the properties globally, or in a with statement which sets the properties via a context manager.

  • To set one or more properties
# Set the property globally.
kvikio.defaults.set({"prop1": value1, "prop2": value2})
kvikio.cufile_driver.set({"prop1": value1, "prop2": value2})

# Set the property with a context manager.
# The property automatically reverts to its old value
# after leaving the `with` block.
with kvikio.defaults.set({"prop1": value1, "prop2": value2}):
with kvikio.cufile_driver.set({"prop1": value1, "prop2": value2}):
    ...
  • To set a single property
# Set the property globally.
kvikio.defaults.set("prop", value)
kvikio.cufile_driver.set("prop", value)

# Set the property with a context manager.
# The property automatically reverts to its old value
# after leaving the `with` block.
with kvikio.defaults.set("prop", value):
with kvikio.cufile_driver.set("prop", value):
    ...

In addition, this PR supports the getter method:

p = kvikio.defaults.get("prop",)
p = kvikio.cufile_driver.get("prop",)

Deprecate the old ways of setting configs

The <prop>_reset and set_<prop> functions are now deprecated. Deprecation warnings (of type FutureWarning) are issued at runtime.

Add Python function is_compat_mode_preferred

The C++ function kvikio::defaults::is_compat_mode_preferred() resolves and queries the current global compat mode. This PR introduces this function to Python.

Python documentation update

@kingcrimsontianyu kingcrimsontianyu added breaking Introduces a breaking change improvement Improves an existing functionality python Affects the Python API of KvikIO c++ Affects the C++ API of KvikIO labels Feb 24, 2025
@kingcrimsontianyu kingcrimsontianyu self-assigned this Feb 24, 2025
Copy link

copy-pr-bot bot commented Feb 24, 2025

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

1 similar comment
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu kingcrimsontianyu marked this pull request as ready for review February 24, 2025 22:52
@kingcrimsontianyu kingcrimsontianyu requested review from a team as code owners February 24, 2025 22:52
@kingcrimsontianyu
Copy link
Contributor Author

Forgot about cuFile's DriverProperties. Sending this PR to draft and working on that.

@kingcrimsontianyu kingcrimsontianyu marked this pull request as draft February 24, 2025 22:59
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

2 similar comments
@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu
Copy link
Contributor Author

/ok to test

@kingcrimsontianyu kingcrimsontianyu marked this pull request as ready for review February 26, 2025 16:11
# TODO: Wrap nicely, maybe as a dataclass?
# <https://github.com/rapidsai/kvikio/issues/526>
DriverProperties = cufile_driver.DriverProperties
properties = cufile_driver.DriverProperties()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think having an instance of DriverProperties() would suffice. So now the settable properties in cufile driver can be set in the following ways:

kvikio.cuda_driver.properties.<prop> = <value>
kvikio.cuda_driver.set("<prop>", <value>) # Can also be used in a "with" statement
kvikio.cuda_driver.set({"<prop>": <value>}) # Can also be used in a "with" statement

Let me know if this looks good enough to you @madsbk

Copy link
Member

@madsbk madsbk left a comment

Choose a reason for hiding this comment

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

Don't we also want to use get for configs like task_size ?

Comment on lines 79 to 89
- To set one or more properties

.. code-block:: python

kvikio.cufile_driver.properties.set({"prop1": value1, "prop2": value2})

- To set a single property

.. code-block:: python

kvikio.cufile_driver.properties.set("prop", value)
Copy link
Member

Choose a reason for hiding this comment

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

Include a context example?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@@ -14,80 +14,86 @@ cdef extern from "<kvikio/defaults.hpp>" namespace "kvikio" nogil:
OFF = 0
ON = 1
AUTO = 2
bool cpp_is_compat_mode_preferred \
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This additional C++ function is needed.

@@ -100,17 +98,16 @@ def test_incorrect_open_mode_error(tmp_path, xp):


@pytest.mark.skipif(
kvikio.defaults.compat_mode(),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a minor bug. By default, compat mode is AUTO, not ON. Here we need to resolve it by using is_compat_mode_preferred() (which necessitates importing its C++ function as mentioned above).

@@ -11,6 +11,24 @@ CuFile
.. autoclass:: IOFuture
:members:

CuFile driver
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added this section, which is missing on the dev branch.

@kingcrimsontianyu
Copy link
Contributor Author

Don't we also want to use get for configs like task_size ?

Done. Added the get method for both kvikio.defaults and kvikio.cufile_driver.

Copy link
Member

@madsbk madsbk left a comment

Choose a reason for hiding this comment

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

Looks great!
Only question is if we should raise a DeprecationWarning ?

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Mar 3, 2025

Only question is if we should raise a DeprecationWarning ?

My preference is usually for a FutureWarning if we want people to actually see them (outside of pytest invoked unit tests, which un-hides DeprecationWarnings).

An exception to this is if it's a component that's typically used by other libraries. Maybe we do want a DeprecationWarning initially so that we can update cuDF to use the new system (I haven't checked if it actually uses the config system anywhere, rather than just docs)? But maybe that's more work than it's worth.

@madsbk
Copy link
Member

madsbk commented Mar 3, 2025

An exception to this is if it's a component that's typically used by other libraries. Maybe we do want a DeprecationWarning initially so that we can update cuDF to use the new system (I haven't checked if it actually uses the config system anywhere, rather than just docs)? But maybe that's more work than it's worth.

Exactly, KvikIO is primarily used by other libraries :)

@bdice
Copy link
Contributor

bdice commented Mar 3, 2025

My preference is usually for a FutureWarning if we want people to actually see them (outside of pytest invoked unit tests, which un-hides DeprecationWarnings).

We exclusively use FutureWarning in cuDF and have recommended all RAPIDS libraries should match that. It’s also how most PyData libraries we’ve studied handle deprecations, to ensure visibility.

@kingcrimsontianyu
Copy link
Contributor Author

Thanks for the discussion. Interesting subtle difference between the two. I'll then keep the use of FutureWarning to be consistent with the recommendations.

@kingcrimsontianyu
Copy link
Contributor Author

/merge

@rapids-bot rapids-bot bot merged commit 4bd58d9 into rapidsai:branch-25.04 Mar 3, 2025
58 checks passed
@kingcrimsontianyu
Copy link
Contributor Author

Thanks for the review!

AyodeAwe pushed a commit to rapidsai/cudf that referenced this pull request Mar 3, 2025
## Description
KvikIO has changed the function names of the config setters to improve
clarity (rapidsai/kvikio#644). This PR updates
the setter calls in cuDF accordingly.

## Checklist
- [x] I am familiar with the [Contributing
Guidelines](https://github.com/rapidsai/cudf/blob/HEAD/CONTRIBUTING.md).
- [x] New or existing tests cover these changes.
- [x] The documentation is up to date with these changes.
@vyasr
Copy link
Contributor

vyasr commented Mar 4, 2025

For posterity, some of our historical discussions around DeprecationWarning and FutureWarning can be found in:

Also worth noting that we have a pre-commit hook in cudf to enforce never using DeprecationWarning, see rapidsai/cudf#11251 and rapidsai/cudf#11255.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Introduces a breaking change c++ Affects the C++ API of KvikIO improvement Improves an existing functionality python Affects the Python API of KvikIO
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Confusion around setting config values Pythonic bindings to cuFIle's driver properties
5 participants