-
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
GC Microbenchmarks Perf Regressions: Move from Segments to Regions #73592
Comments
Tagging subscribers to this area: @dotnet/gc Issue DetailsSummaryThe excessive commit/decommit behavior for regions (in comparison to segments) is regressing for a number of microbenchmarks. Symptoms include a higher number of virtual commits and decommits as regions is more proactive in decommitting memory. Perf ResultsHere are some of the regressions that are found locally running on the following configuration: BenchmarkDotNet=v0.13.1.1786-nightly, OS=Windows 11 (10.0.22000.795/21H2) 1. BenchmarksGame.BinaryTrees_5.RunBenchmark
2. ByteMark.BenchLUDecomp| Criteria | Segments (ms) | Regions (ms) | % Diff | All the associated regressed microbenchmark issues will be added below. How To ReproHow To Repro the Issues With Instrumentation:
|
Conclusion 1: The 3 benchmarks out of the lot we tested that still need further investigation / improvements are:
For 1. we found that there was an improvement in the results from comparing .NET 6’s SDK and .NET 6’s SDK with a clrgc.dll from .NET 8 Preview 7 AND .NET 8 with Segments and .NET 8 with a less precise Write Barrier and Write XOR Execute turned off (23% to 5%); this improvement, however, was still not enough to get us back to the same level as segments. We still need to analyze 2. And 3. – we observed that running the default invocation count isn’t enough to capture enough samples while looking at the CPU traces. Conclusion 2: Disabling Mark Phase Prefetch reversed regressions for several benchmarks. As far as I recall, we did have an exception for enablement of this feature. The data are as follows: List of Regressions With Mark Phase Prefetch (7)
List of Regressions Without Mark Phase Prefetch (2)
Conclusion 3: A lot of the regressions for which we were assigned bugs for no longer show up as regressions after conducting a comparison in a GC-centric way. As a clear-cut example:
All Tests Run
|
Summary
A number of microbenchmarks regressed after moving from representing the GC Heap from Segments to Regions; the reason was attributed to the increase in the commit/decommits. Symptoms include a higher number of virtual commits and decommits as regions is more proactive in decommitting memory.
Perf Results Comparing NET 6.0 vs. NET 8.0
Regressed benchmarks:
This is an improvement from Net7.0 that exhibited the following regressions:
Perf Results from Net7.0
Here are some of the regressions that are found locally running on the following configuration:
BenchmarkDotNet=v0.13.1.1786-nightly, OS=Windows 11 (10.0.22000.795/21H2)
Intel Core i9-10900K CPU 3.70GHz, 1 CPU, 20 logical and 10 physical cores
.NET SDK=7.0.100-rc.1.22375.2
[Host] : .NET 7.0.0 (7.0.22.36704), X64 RyuJIT
Job-YRVDKS : .NET 7.0.0 (42.42.42.42424), X64 RyuJIT
1. BenchmarksGame.BinaryTrees_5.RunBenchmark
2. ByteMark.BenchLUDecomp
All the associated regressed microbenchmark issues will be added below.
How To Repro
How To Repro the Issues With Instrumentation:
a.
set complus_GCLogEnabled=1
b.
set complus_GCLogFileSize=100
c.
set complus_GCLogFile=c:\logs\<name>
d.
set complus_StressLog=0
a.
cd <path to the performance repo>
b. Run the benchmark using
py .\scripts\benchmarks_ci.py --filter <Name of Benchmark e.g. ByteMark.BenchLUDecomp> -f net7.0 --corerun <Path to Corerun>
c. Record the mean time from Benchmark.Net and the results from the instrumentation.
The text was updated successfully, but these errors were encountered: