Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Refactor engine JIT stage#2806

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
timcassell wants to merge5 commits intomaster
base:master
Choose a base branch
Loading
fromjit-stage
Open

Refactor engine JIT stage#2806

timcassell wants to merge5 commits intomasterfromjit-stage

Conversation

timcassell
Copy link
Collaborator

@timcasselltimcassell commentedJul 9, 2025
edited
Loading

Fixes#2004
Fixes#1466
Contributes to#2787,#1993,#1780,#1210

  • Moved JIT stage fromEngineFactory to a properEngineJitStage.
    • JIT stage now attempts to push the benchmarked method through all JIT tiers.
  • Moved heuristic fromEngineFactory to a new pilot stage (JIT stage, according to its name, now only focuses on jitting).
    • Fixed the heuristic to never include the first invocation.
  • Cleanup aroundIEngine (breaking changes).
  • Improved check forLegacyJit.

yield return GetOverheadNoUnrollIterationData();
yield return GetDummyIterationData(dummy2Action);
yield return GetWorkloadNoUnrollIterationData();
yield return GetDummyIterationData(dummy3Action);
Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

@AndreyAkinshin You added dummy actions in 2017. I don't know what they are for. Do we still need them?

@timcassell
Copy link
CollaboratorAuthor

cc@AndyAyersMS@EgorBo

@EgorBo
Copy link
Member

JIT stage now attempts to push the benchmarked method through all JIT tiers.
Set environment variable for the runtime to enable aggressive tiering by default.

Honestly, I think you shouldn't useTC_AggressiveTiering, just 1 iteration to promote to Tier1 is mostly just for internal testing. I thinkCallCountingDelayMs=0 should be enough.

@timcassell
Copy link
CollaboratorAuthor

Honestly, I think you shouldn't useTC_AggressiveTiering, just 1 iteration to promote to Tier1 is mostly just for internal testing. I thinkCallCountingDelayMs=0 should be enough.

Can you elaborate on that? Why would we need more than 1 invocation per tier for throughput benchmarks? 30 invocations is too much for the stage to complete in a timely manner for long-running benchmarks.

Also, I triedCallCountingDelayMs=0, but it breaks the disassembler (dotnet/runtime#117339).

@EgorBo
Copy link
Member

EgorBo commentedJul 13, 2025
edited
Loading

Can you elaborate on that?

I think the profile will not be representable (a benchmark may invoke the same method from different places and we don't have context-sensitive profiling yet) + we have optimizations like we intentionally make call counting for some methods smaller so their callers are guaranteed to be promoted later (it's for some internal calls so we can bake final addresses of their Tier1 code versions directly instead of having indirect calls), although, I am mostly concerned about PGO quality.

@timcassell
Copy link
CollaboratorAuthor

Thanks, that makes sense. I guess I can remove that env var and just run the jit stage with a timeout, and if it doesn't fully reach tier1, we can allow the pilot/warmup stages to handle it later (#1210).

Can you also verify the logic inJitInfo.cs?

@EgorBo
Copy link
Member

Thanks, that makes sense. I guess I can remove that env var and just run the jit stage with a timeout, and if it doesn't fully reach tier1

How do you check that? I don't think there is a way to check whether a benchmark and all of its callees are fully warmed up

@timcassell
Copy link
CollaboratorAuthor

Thanks, that makes sense. I guess I can remove that env var and just run the jit stage with a timeout, and if it doesn't fully reach tier1

How do you check that? I don't think there is a way to check whether a benchmark and all of its callees are fully warmed up

We don't. We just run a number of invocations based on the configured values retrieved fromJitInfo and hope for the best. The pilot/warmup stages will have to work with some sort of heuristic to try to determine if tiering caused the measured time to significantly drop.

EgorBo reacted with thumbs up emoji

@timcasselltimcassellforce-pushed thejit-stage branch 2 times, most recently from8a143d6 tof02de9bCompareJuly 13, 2025 21:42
@timcassell
Copy link
CollaboratorAuthor

dotnet/runtime#117787 (comment)

The "third tier" you see may be OSR, since your method loops a lot and isn't called often.

@AndyAyersMS (to not derail that issue), how can we account for OSR in the jit stage here?

@EgorBo
Copy link
Member

EgorBo commentedJul 17, 2025
edited
Loading

dotnet/runtime#117787 (comment)

The "third tier" you see may be OSR, since your method loops a lot and isn't called often.

@AndyAyersMS (to not derail that issue), how can we account for OSR in the jit stage here?

I think for BDN specifically OSR is just some intermediate tier it doesn't have to care about, it shouldn't impact the Tier0->Tier1 promotion velocity. Since the method is too slow, I guess BDN decided not too call it too many times?

@timcassell
Copy link
CollaboratorAuthor

Since the method is too slow, I guess BDN decided not too call it too many times?

This is purely for the jit stage, where the number of invocations are fixed (in an attempt to push it through all tiers). I'm not sure what the jit thinks is not called enough times. Perhaps because of how the stages work, it only invokes once per iteration, and the jit can't see that the iterations are being ran multiple times? If we called it through theWorkloadUnroll method (withunrollFactor = 16), the jit would skip the OSR?

@timcassell
Copy link
CollaboratorAuthor

timcassell commentedJul 17, 2025
edited
Loading

I think for BDN specifically OSR is just some intermediate tier it doesn't have to care about, it shouldn't impact the Tier0->Tier1 promotion velocity.

That's what I thought, but the evidence shows otherwise. It took 60 invocations to fully reach tier1, instead of 30 (DPGO disabled).

@AndyAyersMS
Copy link
Member

Did you try profiling the example fromdotnet/runtime#117787? If not, I can do it soonish.

@timcassell
Copy link
CollaboratorAuthor

Did you try profiling the example fromdotnet/runtime#117787? If not, I can do it soonish.

Nope, I don't have much experience to know what to look for. If you're going to do it from this branch, add +2 toremainingTiers in the jit stage to see results of all tiers. Appreciate it.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@AndreyAkinshinAndreyAkinshinAwaiting requested review from AndreyAkinshin

Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Wildly different results from simply swapping the order of benchmarks Unoptimized code is used for benchmark
3 participants
@timcassell@EgorBo@AndyAyersMS

[8]ページ先頭

©2009-2025 Movatter.jp