-
Notifications
You must be signed in to change notification settings - Fork 103
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
Add event timing #481
Add event timing #481
Conversation
/ok to test |
This comment has been minimized.
This comment has been minimized.
/ok to test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the semantics of this implementation. It wouldn't have thought that you could directly subtract two Event
s to get the difference between them in time, but I like it.
One thing that may be missing is documentation of what happens if timing is not enabled. What is the expected behavior? I suspect the answer is that the difference is zero, but raising an error because we tried to do timing without enabling timing seems more pythonic.
Currently we do raise an exception since the driver API would return an error if the events were created without timing enabled:
So the question is if we want to do an exception chaining and raise, say, |
We ensure this exception is raised in commit 8aca468. The discussion for an optional exception chaining is still open. |
If it's possible to catch and reraise the error with a message like "Timing must be enabled in order subtract Events. Events have timing disabled by default." That would be better than "invalid resource handle". |
/ok to test |
This is ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing the code now, I like the exception chaining approach better than the idea I posted before.
Thanks, Ralf/Daniel! |
|
When working on #475 (68c9365) I noticed we surprisingly haven't implemented event-based timing... Looks like an oversight to me because we did spend a lot of time discussing the default of the
enabling_timing
option and how to retrieve the timing result. This PR adds the implementation, which is also aligned with thecuda::experimental::timed_event
treatment:https://github.com/NVIDIA/cccl/blob/096596b3580d6cb2042fff692e8162d2a0ea356b/cudax/include/cuda/experimental/__event/timed_event.cuh#L90