System.Threading.Tests.Perf_Timer.SynchronousContention has regressed on macOS x64 #66774
Comments
adamsitnik
added
area-System.Threading
os-mac-os-x
|
Tagging subscribers to this area: @mangod9 Issue DetailsSystem.Threading.Tests.Perf_Timer.SynchronousContentionThis particular benchmark has regressed even up to x10. I happened between preview 1 and preview 2 and is specific to macOS x64 . All Other configs are fine. Repro: git clone https://github.com/dotnet/performance.git
python3 ./performance/scripts/benchmarks_monthly.py net6.0 net7.0-preview2 --filter 'System.Threading.Tests.Perf_Timer.SynchronousContention'6.0 vs 7.0-preview2
6.0 vs 7.0-preview1no regression
cc @kouvel
|
|
Looks like the perf on "macOS Big Sur" is similar on preview 2 as on preview 1. "macOS Monterey" appears to be new in the preview 2 runs, maybe it's something specific to Monterey. |
|
There are some simpler benchmarks like System.Collections.CtorGivenSizeNonGeneric.Queue(Size: 512)
|
|
Here's a narrower repro: using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Threading;
static class Program
{
private static void Main()
{
int threadCount = Environment.ProcessorCount;
var threadReady = new AutoResetEvent(false);
var continueThreads = new ManualResetEvent(false);
int completedThreadCount = 0;
var allThreadsCompleted = new AutoResetEvent(false);
TimerCallback timerCallback = _ => { };
ThreadStart threadStart = () =>
{
threadReady.Set();
continueThreads.WaitOne();
for (int i = 0; i < 1_000_000; i++)
{
CreateFinalizable();
}
if (Interlocked.Increment(ref completedThreadCount) >= threadCount)
{
continueThreads.Reset();
completedThreadCount = 0;
allThreadsCompleted.Set();
}
};
var sw = new Stopwatch();
for (int j = 0; j < 4; j++)
{
for (int i = 0; i < threadCount; i++)
{
var t = new Thread(threadStart);
t.IsBackground = true;
t.Start();
threadReady.WaitOne();
}
sw.Restart();
continueThreads.Set();
allThreadsCompleted.WaitOne();
sw.Stop();
Console.WriteLine($"{sw.Elapsed.TotalMilliseconds,10:0.000}");
}
}
[MethodImpl(MethodImplOptions.NoInlining)]
private static void CreateFinalizable() => new TestObjWithFinalizable();
private sealed class TestObjWithFinalizable
{
private readonly TestFinalizable _testFinalizable = new TestFinalizable();
}
private sealed class TestFinalizable
{
public TestFinalizable() => GC.SuppressFinalize(this);
~TestFinalizable() { }
}
}On my 2-core 4-thread x64 macOS Monterey: .NET 6: .NET 7 preview 1: .NET 7 preview 2: The numbers on the latest .NET 7 were ranging between 1300 and 2000. I'm not sure what might have changed, but it seems related to the GC. On other systems I'm seeing a large portion of CPU time spent under CC @dotnet/gc |
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsSystem.Threading.Tests.Perf_Timer.SynchronousContentionThis particular benchmark has regressed even up to x10. I happened between preview 1 and preview 2 and is specific to macOS x64 . All Other configs are fine. Repro: git clone https://github.com/dotnet/performance.git
python3 ./performance/scripts/benchmarks_monthly.py net6.0 net7.0-preview2 --filter 'System.Threading.Tests.Perf_Timer.SynchronousContention'6.0 vs 7.0-preview2
6.0 vs 7.0-preview1no regression
cc @kouvel
|
|
so there is a regression only on macOS x64 and not arm64? |
In the 6.0 vs 7.0-preview2 comparison above, 7.0p2 appears to be faster on the benchmark on macOS Monterey arm64. |
|
since this is macOS x64 only moving to 8 |
|
Closing since this was MacOS x64 specific. |
ghost
locked as resolved and limited conversation to collaborators
System.Threading.Tests.Perf_Timer.SynchronousContention
This particular benchmark has regressed even up to x10. I happened between preview 1 and preview 2 and is specific to macOS x64 . All Other configs are fine.
Repro:
6.0 vs 7.0-preview2
6.0 vs 7.0-preview1
no regression
cc @kouvel
The text was updated successfully, but these errors were encountered: