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

removing unused NoOpHeuristic #3670

Merged
merged 4 commits into from
Jan 13, 2025
Merged

removing unused NoOpHeuristic #3670

merged 4 commits into from
Jan 13, 2025

Conversation

jjsjann123
Copy link
Collaborator

@jjsjann123 jjsjann123 commented Jan 3, 2025

  1. Removing unused NoOpHeuristic;
  2. Moving computation of scheduler/launch params into the block when it's needed.

@jjsjann123
Copy link
Collaborator Author

!test

const auto& compile_log = executor_cache->getMostRecentExecutorInfo();
auto params = toString(compile_log.params);
auto lparams = toString(
compile_log.fusion_executor->as<KernelExecutor>()->lastLaunchParams());
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

only compute these when needed.

i.e. if segmentation happens with NoOp segment, the toString method above would fail.

Copy link
Collaborator

Choose a reason for hiding this comment

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

What do you mean by if segmentation happens with NoOp segment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If segmentation happened and gives no-op segments, since toString here isn't expecting no-op scheduler, we run into asserts.

NVF_THROW(
"Unknown heuristic parameter type. Did you just added a new heuristic parameter type but forget to update here?");

@naoyam
Copy link
Collaborator

naoyam commented Jan 6, 2025

I'm not sure why NoOpHeuristic needs to be returned? Looks like it's no longer used. Isn't it just that the util function of the old benchmarks would need to be updated?

@jjsjann123
Copy link
Collaborator Author

I'm not sure why NoOpHeuristic needs to be returned? Looks like it's no longer used. Isn't it just that the util function of the old benchmarks would need to be updated?

We don't have to. I'll remove NoOpHeuristic then.

@jjsjann123
Copy link
Collaborator Author

!test

@jjsjann123 jjsjann123 changed the title NoOpScheduler::computeHeuristics should return NoOpHeuristic removing unused NoOpHeuristic Jan 13, 2025
Copy link
Collaborator

@naoyam naoyam left a comment

Choose a reason for hiding this comment

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

LGTM

@jjsjann123
Copy link
Collaborator Author

failing test coming from CUDA_ERROR_MISALIGNED_ADDRESS looks to be not related to this PR. I'm merging this one.

@jjsjann123 jjsjann123 merged commit de04f12 into main Jan 13, 2025
43 of 44 checks passed
@jjsjann123 jjsjann123 deleted the no_op_heuristic branch January 13, 2025 23:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants