[Perf -35%] System.Threading.Tests.Perf_Thread.GetCurrentProcessorId

[DrewScoggins]

Run Information

Architecture	x64
OS	Windows 10.0.18362
Changes	diff

Regressions in System.Threading.Tests.Perf_Thread

Benchmark	Baseline	Test	Test/Base	Modality	Baseline Outlier
GetCurrentProcessorId	4.26 ns	5.74 ns	1.35		False

Historical Data in Reporting System

Repro

git clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f netcoreapp5.0 --filter 'System.Threading.Tests.Perf_Thread*';

Histogram

System.Threading.Tests.Perf_Thread.GetCurrentProcessorId

[3.832 ; 4.527) | @@@@
[4.527 ; 5.222) | 
[5.222 ; 6.112) | @@@@@@@@@@@@@@@
[6.112 ; 6.602) | @@@
[6.602 ; 6.862) | 
[6.862 ; 7.557) | @

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[DrewScoggins]

@adamsitnik @VSadov

[VSadov]

GetCurrentProcessorId was "fast" previously because of aggressive caching. It would return the same result for 3000 invocations (or was it 50000 invocations?, i do not remember..)

Since the threads can move between cores, long caching diminishes the value of this API. We saw problems with that.
However there are machines/OSs/hypervisors where underlying implementation is very slow (on order of 1000x slower than fast systems) and such caching could be the only way to not make this API an occasional perf trap.

The change was to measure the underlying implementation and adjust caching accordingly.
The goal was to improve precision on systems where it is possible, while not regressing hopelessly on older/slower systems.

Since, I assume you have a relatively modern system, the former performance of this API was basically measuring access to a thread local. Not much real work was happening comparatively.

35% is acceptable regression in this case. The calibration expects that "working" implementation will be a bit more expensive than just fetching a value from TLS.

3x-5x regression would be alarming. It would mean our measurements are off.

[mangod9]

Closing based on analysis above.

[adamsitnik]

FWIW I got data from more machines and the regression is not bigger than a few nanoseconds so it's still acceptable and I am keeping it closed at it was.

System.Threading.Tests.Perf_Thread.GetCurrentProcessorId

Conclusion	Base	Diff	Base/Diff	Modality	Operating System	Bit	Processor Name	Base Runtime	Diff Runtime
Slower	6.10	6.90	0.88		Windows 10.0.18363.1016	Arm	Microsoft SQ1 3.0 GHz	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Slower	3.21	4.41	0.73		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20404.3
Slower	3.21	4.52	0.71		Windows 10.0.18363.959	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Slower	4.09	5.93	0.69		Windows 10.0.19041.450	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20413.9
Slower	3.38	5.58	0.61		Windows 10.0.19041.450	X64	Intel Core i7-6700 CPU 3.40GHz (Skylake)	.NET Core 3.1.6	5.0.100-rc.1.20419.9
Slower	2.96	4.33	0.68	several?	Windows 10.0.19042	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3
Slower	2.20	3.32	0.66		Windows 10.0.18363.959	X86	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20420.2
Slower	2.57	3.96	0.65		Windows 10.0.19041.450	X86	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20419.5
Slower	4.54	8.01	0.57		ubuntu 18.04	X64	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 3.1.6	5.0.100-rc.1.20403.23
Same	6.51	4.76	1.37	bimodal	macOS Mojave 10.14.5	X64	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 3.1.6	5.0.100-rc.1.20404.2
Slower	8.36	9.67	0.86		ubuntu 18.04	X64	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 3.1.6	5.0.100-rc.1.20418.3