[2.2] Disable tiered compilation by default for 2.2 RTM

[kouvel]

Description

A fix for https://github.com/dotnet/coreclr/issues/19752 appears to be desired before enabling tiered compilation by default for 2.2. Some small steady-state performance regressions (~5%) have been seen in TechEmpower benchmarks running without the R2R (TechEmpower runs benchmarks on aspnetcore with COMPlus_ReadyToRun=0). In default mode, where R2R is enabled and the aspnetcore shared framework is used, tiered compilation typically improves steady-state performance. The fix is not too small and involves some risk that does not appear to be appropriate for 2.2, so this change disables tiered compilation by default for 2.2 RTM.

Customer impact

• Eliminates regressions from tiered compilation
• Improvements from tiered compilation being enabled would be lost by default. Customers may still choose to enable tiered compilation.

Regression?

No

Packaging reviewed?

Yes, no impact (coreclr only)

Risk

Low, CI has also been testing with tiered compilation disabled

[noahfalk]

I imagine this commit text could get some publicity from people worried that they shouldn't turn on tiered compilation, so I think we should be very explicit about what conditions are being compared to generate this 5% difference, and whether or not any customer is likely to find themselves in this state via a normal development/deployment scenario.

You described it above as 'without R2R'ed ASP.NET shared framework', but I wanted to double check as I had a different understanding (and I could be dead wrong ; ). My assumption is that the perf lab was measuring with all R2R and fragile NGEN disabled - in particular, that assemblies such as System.Private.CoreLib.dll and System.Net.dll were being jitted. The only normal dev scenario I am aware of that approaches this level of jitting is packaging the app as a self-contained app but even that may not disable enough pre-compiled code to show the 5% delta?

[noahfalk]

The code change looked good to me, my only concern is to confirm the commit text accurately describes the perf measuring conditions.

[benaadams]

My assumption is that the perf lab was measuring with all R2R and fragile NGEN disabled - in particular, that assemblies such as System.Private.CoreLib.dll and System.Net.dll were being jitted.

It runs with the environment flag

ENV COMPlus_ReadyToRun 0

TechEmpower/FrameworkBenchmarks/.../aspcore.dockerfile

[kouvel]

Clarified inline above

[noahfalk]

thanks for timely info @benaadams 👍

[AndyAyersMS]

Did we get any other feedback from enabling tiering in the 2.2 previews?

I know of #20421 but that came from somebody looking at 3.0....

[kouvel]

I have not seen much concrete feedback from 2.2 previews so far. A couple of mentions of known perf issues, and generic posts here and there is all I saw.

[kouvel]

@dotnet-bot test Ubuntu arm64 Cross Debug Innerloop Build

[kouvel]

@dotnet-bot test this please

[vivmishra]

Approved for 2.2 RTM

[kouvel]

@dotnet-bot test Windows_NT x64 Formatting

[kouvel]

@dotnet-bot test this please

[kouvel]

@dotnet-bot test Windows_NT x64 perf scenarios
test Windows_NT x64 min_opts perf scenarios
test Windows_NT x86 perf scenarios
test Windows_NT x86 min_opts perf scenarios

[kouvel]

@dotnet-bot test Windows_NT x64 Formatting

The following jobs seem to be broken, as seen in the test job #20570, the failures are not caused by this change:

• Ubuntu arm64 Cross Debug Innerloop Build
• Windows_NT x64 full_opt ryujit Performance Scenarios Tests
• Windows_NT x86 full_opt ryujit Performance Scenarios Tests

[kouvel]

@dotnet-bot test Windows_NT x64 Formatting