-
Notifications
You must be signed in to change notification settings - Fork 275
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
Experiment Report: Using BenchmarkDotNet to find methods that can cause longe GC pause times #1049
Comments
In the next step, I've run all the benchmarks we have in this repo and wrote a small parser that sorted them descending by average reported time. The full results can be obtained here: https://gist.github.com/adamsitnik/e31284814b44bcb3078825e0018a1ea3#file-windows_results-txt Top:
|
I've taken a brief look at the results to verify that they are correct. The worst is
And internally performs an fcall to Which means that calling some of the |
@jkotas please let me know if you want some more information or confirmation. I am not going to investigate all the methods right now because you most probably know how they are implemented and can quickly tell where the problems are and what is by design ;) |
We currently have an issue with many of the math functions that different platform/architecture combinations have different implementations and so compute different results and can have wildly different performance characteristics. So it might be worth also getting results on Linux and macOS for these to help compare/contrast. |
Nice experiment and analysis, @adamsitnik. |
Very nice! |
So, looking at the fact that calling I can easily imagine a loop doing just math and trivial FCALLs - more math, typesystem/VM helpers like casts and threadstatics, @jkotas - How is that actually handled? |
FCALLs are supposed to poll for GC to avoid GC starvation. Many FCALLs are missing the polls. We can fix this by either adding the GC polls to all FCALLs that we find problematic; or teaching the JIT to generate the GC poll around every FCALL call (ie use the same GCPoll logic as SuppressGCTransition that was introduced recently). |
I have opened https://github.com/dotnet/coreclr/issues/27931 and |
I've run the experiment for Ubuntu 18.04 using exactly same hardware (my PC with dual boot) Full results: https://gist.github.com/adamsitnik/e31284814b44bcb3078825e0018a1ea3#file-linux_results-txt Top 100:
|
Linux vs Windows comparison, sorted descending by sum of medians: https://gist.github.com/adamsitnik/e31284814b44bcb3078825e0018a1ea3#file-linux_vs_windows-txt top 100:
|
I've reported an issue I've hit when I was running the benchmarks: dotnet/runtime#314 @jkotas pleas let me know if you need any more data. |
Thanks! We have issues opened on the top problems found by this experiment. |
I was asked by @jkotas if it would be possible to run a simple experiment using BenchmarkDotNet and find methods that can cause long GC pause times. Examples: https://github.com/dotnet/coreclr/issues/27106 https://github.com/dotnet/coreclr/issues/27683
I took the idea from following @jkotas example:
And hacked BenchmarkDotNet to:
GC.Collect(); Thread.Sleep(1);
and reports the time it takes to execute itSo more or less the reported times were GC pause times.
More details: dotnet/BenchmarkDotNet@fb57a14
To verify that it works I've used the following example:
Which has produced the following results for 2.1 (where the
Array.Sort
still calls native sort implementation and causes the problem):BenchmarkDotNet=v0.12.0.20191121-develop, OS=Windows 10.0.18363
Intel Xeon CPU E5-1650 v4 3.60GHz, 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=5.0.100-alpha1-013817
[Host] : .NET Core 2.1.13 (CoreCLR 4.6.28008.01, CoreFX 4.6.28008.01), X64 RyuJIT
Job-JTLBSN : .NET Core 2.1.13 (CoreCLR 4.6.28008.01, CoreFX 4.6.28008.01), X64 RyuJIT
IterationTime=250.0000 ms MaxIterationCount=5 MinIterationCount=3
WarmupCount=1
So as you can see the
Reverse
andBubbleSort
despite doing more work for already sorted array report an order of magnitude less time thanSort
.The text was updated successfully, but these errors were encountered: