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

Sampling overlay prototype #117

Closed

Conversation

DavidPoliakoff
Copy link
Contributor

Based on kokkos/kokkos#3812

One hope I have for that design is that our simple tools can be given complex capabilities using "overlays," (a concept I'm shamelessly stealing from @nmhamster and @jrmadsen ). This PR introduces some infrastructure to enable that concept, and two example overlays.

First, I formalized the process for forwarding your callbacks to a next tool, using a "callback_chainer" struct, which handles loading a next library, grabbing callbacks, all that mess.

The first example overlay is a trivial "passthrough" overlay. All it does is forward events, I basically used it to prove out the callback_chainer thing.

The other is a sampler overlay. This turns off Kokkos global fencing, and then every 101 kernel invocations (that should be a settable parameter) it forwards the kernel to an underlying tool. Fences are only introduced in the case where the kernel is profiled. I've tested this with the space-time-stack and TAU (TAU through modifying tau_exec).

What's neat here is that space-time-stack is completely unmodified, but gets this sampling capability "for free." It's kind of a deeply weird version of a modular tools framework.

Not sure how I feel about this design as a thing to merge, mainly just putting it up as another proof of concept for the Core PR

static uint64_t encounter;
++encounter;
if ((encounter % sample_rate) == 0) {
actions.fence(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

Making a comment for myself (David, you don't need to respond to this of course) that I think this parameter to fence function should not have to be zero.

@vlkale vlkale mentioned this pull request Apr 11, 2024
@vlkale
Copy link
Contributor

vlkale commented Jun 3, 2024

I am closing this PR as no further work needs to be done on it currently within the Kokkos team, and its underlying goals have been accomplished via the recently merged #213. There are some new ideas here not in PR #213. However, having talked with @(DavidPoliakoff), this can be brought back to life if there is a Kokkos Tools user request / Kokkos Tools GitHub issue that necessitates it.

@vlkale vlkale closed this Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants