-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
QuickJitForLoops causing regressions #80210
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsDescriptionI am noticing some of the microbenchmarks perform worse or take longer before TieredCompilation can fully optimize. Specifically, this looks to be due to the For example, if I run some of the microbenchmarks using .NET 7.0 with default settings, I get worse performance than if I run with Using
Using
ConfigurationAll benchmarks were run on various x64 systems (AMD Zen 3, AMD Zen 4, and Intel Rocket Lake). Baseline .NET version used is .NET 6.0.12. Comparison .NET version used is .NET 7.0.1. I ran two comparisons:
Regression?Yes, this is a regression going from .NET 6.0.12 -> .NET 7.0.1. DataI've noticed these microbenchmarks are affected by this:
|
In general it was expected that certain microbenchmarks would be regressions due to various interactions between on-stack replacement and how Benchmark.NET works. @AndyAyersMS analyzed most of them in #33658 and #67594. |
Right, mostly benchmarks whose invocation times are on the order of 100ms or more that spend most of their time in a single method. When this happens BDN does not run many invocations per iteration, and so code being tested does not have a chance to tier up, and inevitably also contains loops, hence BDN ends up measuring the perf of the OSR version of the method. There are a variety of reasons why the OSR code may be less efficient than the tiered up method code. I have ideas on how to mitigate some these (see the linked issues above) but nothing committed or scheduled. |
Description
I am noticing some of the microbenchmarks perform worse or take longer before TieredCompilation can fully optimize. Specifically, this looks to be due to the
DOTNET_TC_QuickJitForLoops
configuration setting.For example, if I run some of the microbenchmarks using .NET 7.0 with default settings, I get worse performance than if I run with
DOTNET_TC_QuickJitForLoops=0
.Using
.\Microbenchmarks.exe --filter 'FractalPerf.Launch.Test'
:Using
.\Microbenchmarks.exe --filter 'FractalPerf.Launch.Test' --envVars DOTNET_TC_QuickJitForLoops:0
:Configuration
All benchmarks were run on various x64 systems (AMD Ryzen and Intel).
Baseline .NET version used is .NET 6.0.12.
Comparison .NET version used is .NET 7.0.1.
I ran two comparisons:
Regression?
Yes, this is a regression going from .NET 6.0.12 -> .NET 7.0.1.
Data
I've noticed these microbenchmarks are affected by this:
The text was updated successfully, but these errors were encountered: