[Preview 4] Disable tier 0 JIT (quick JIT) by default, rename config option #23599
Conversation
Depends on dotnet#23599 - Renamed tier 0 / tier 1 to StartupTier, OptimizedTier - Added config option QuickJitForLoops, which determines whether quick JIT, when enabled, may be used for methods that contain loops. Off by default, so after this change, StartupTierQuickJit=1 or ForceQuickJit=1 would still not use quick JIT for methods that contain loops by default.
Is the plan to switch it back on by default at some point? As it does make steady state code better when it gets there over both initial Tier1 (due to things like |
|
Tiering up from R2R code to optimized jitted code is still enabled. Methods that don't have R2R code would skip the quick JIT and go straight to the optimized one. As we get more information on what kind of issues may occur with the quick JIT code it may stabilize enough to enable again. |
|
Perf results are here: #23597 (comment) Except that with this change, Tier+QJ is equivalent in perf to the numbers in the Tier+QJ+QJL columns in the numbers above (QuickJit=1 enables quick-jitting methods that contain loops). |
|
@dotnet-bot test Ubuntu x64 Checked CoreFX Tests |
|
What is the intended purpose of Showing perf impact as percentage change from some other configuration as in #23597 seems odd. Would like to see the results impacted by this change compared directly instead. Say a table here with just (old default) vs (new default). |
|
Posted new tables comparing after vs before directly, and after vs no-tier here: #23597 (comment) The purpose of |
|
Posting perf numbers here as well. Lower is better for all diffs. JitBench startup perf - time (ms)
ASP.NET startup perf - time (ms), server start + first request
JitBench startup perf - R2R disabled
ASP.NET startup perf - R2R disabled - time (ms), server start + first request
JitBench steady-state perf - time (ms)
ASP.NET steady-state perf - time (ns) per request
|
Depends on dotnet#23599 - Renamed tier 0 / tier 1 to StartupTier, OptimizedTier - Added config option QuickJitForLoops, which determines whether quick JIT, when enabled, may be used for methods that contain loops. Off by default, so after this change, StartupTierQuickJit=1 or ForceQuickJit=1 would still not use quick JIT for methods that contain loops by default.
No they will only be jitted once at tier 1. Those methods reach this path: When call counting is disabled in the startup tier, it affects the initial optimization tier for the method: That is used for the default |
Depends on dotnet#23599 - Renamed tier 0 / tier 1 to StartupTier, OptimizedTier - Added config option QuickJitForLoops, which determines whether quick JIT, when enabled, may be used for methods that contain loops. Off by default, so after this change, StartupTierQuickJit=1 or ForceQuickJit=1 would still not use quick JIT for methods that contain loops by default.
|
@kouvel - just so it isn't surprising later, I have mixed feelings about the current config names. I'm fine to discuss that in the context of final naming we use in 3.0 RTM and did not want to hold up your work here changing the Preview4 defaults. |
|
Maybe we can have a quick chat about that soon. I'm not sure if anyone will be enabling the |
Depends on dotnet#23599 - Renamed tier 0 / tier 1 to StartupTier, OptimizedTier - Added config option QuickJitForLoops, which determines whether quick JIT, when enabled, may be used for methods that contain loops. Off by default, so after this change, StartupTierQuickJit=1 or ForceQuickJit=1 would still not use quick JIT for methods that contain loops by default.
- Tier 0 JIT is being called quick JIT in config options, renamed DisableTier0Jit to StartupTierQuickJit - Disabled quick JIT by default, the current plan is to do that for preview 4 - Concerns were that code produced by quick JIT may be slow, may allocate more, may use more stack space, and may be much larger than optimized code, and there there may be many cases where these things lead to regressions when the span of time between startup and steady-state is important - The thought was that with quick JIT disabled, tiering overhead from call counting and backgorund jitting with optimizations would be less, and perf during any point in time would be closer to 2.x releases - This mostly loses the startup perf gains from tiering. It may also be slightly slower compared with tiering off due to some overhead. When quick JIT is disabled for the startup tier, made a change to disable tiered compilation for methods in modules that are not R2R'ed since they will not be tiered currently anyway. The overhead and regression in R2R'ed modules will be looked into separately to see if it can be reduced. - Added config option ForceQuickJit, which uses quick JIT instead of the normal JIT. Off by default. Disables tiering. Fixes https://github.com/dotnet/coreclr/issues/22998 Fixes https://github.com/dotnet/coreclr/issues/19751
Depends on dotnet#23599 - Renamed tier 0 / tier 1 to StartupTier, OptimizedTier - Added config option QuickJitForLoops, which determines whether quick JIT, when enabled, may be used for methods that contain loops. Off by default, so after this change, StartupTierQuickJit=1 or ForceQuickJit=1 would still not use quick JIT for methods that contain loops by default.
|
In |
The old snapshot is by design for the time being. PRs that hit issues with the old snapshot of CoreFX tests are expected to disable the offending tests in https://github.com/dotnet/coreclr/blob/master/tests/CoreFX/CoreFX.issues.json Could you please submit PR to disable the offending test to make the CI on master green? |
|
Oh ok, will do |
|
@dotnet/jit-contrib we need to look at what this does to our CI test coverage. We should make sure we have some runs where TC is enabled that also turn on "quick jit." |
…option (dotnet/coreclr#23599) Disable tier 0 JIT (quick JIT) by default, rename config option - Tier 0 JIT is being called quick JIT in config options, renamed DisableTier0Jit to StartupTierQuickJit - Disabled quick JIT by default, the current plan is to do that for preview 4 - Concerns were that code produced by quick JIT may be slow, may allocate more, may use more stack space, and may be much larger than optimized code, and there there may be many cases where these things lead to regressions when the span of time between startup and steady-state is important - The thought was that with quick JIT disabled, tiering overhead from call counting and backgorund jitting with optimizations would be less, and perf during any point in time would be closer to 2.x releases - This mostly loses the startup perf gains from tiering. It may also be slightly slower compared with tiering off due to some overhead. When quick JIT is disabled for the startup tier, made a change to disable tiered compilation for methods in modules that are not R2R'ed since they will not be tiered currently anyway. The overhead and regression in R2R'ed modules will be looked into separately to see if it can be reduced. Fixes https://github.com/dotnet/coreclr/issues/22998 Fixes https://github.com/dotnet/coreclr/issues/19751 Commit migrated from dotnet/coreclr@b4390c4
The environment variable is
COMPlus_TC_QuickJit, it's0by default and may be set to1to enable.Fixes https://github.com/dotnet/coreclr/issues/22998
Fixes https://github.com/dotnet/coreclr/issues/19751