-
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
Regression in PerfLabTests.LowLevelPerf.GenericClassWithIntGenericInstanceField #13770
Comments
For issues tracking "step function" regressions like this one can you please include a link to the commits that occurred at the point of the regression? |
cc @AndyAyersMS |
@DrewScoggins is the lab running with tiering enabled? If so I'm puzzled why the 5.0 numbers fluctuate the way they do. Locally the 3.0/3.1 results seem bi-stable too:
and the codegen for all 3 versions is identical: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT; X.GenericClassWithIntGenericInstanceField()
xor eax,eax
mov edx,[7FFDDE98B24C]
test edx,edx
jle short M00_L01
M00_L00:
mov rcx,19D269D2C98
mov rcx,[rcx]
mov dword ptr [rcx+0C],1
inc eax
cmp eax,edx
jl short M00_L00
M00_L01:
ret
; Total bytes of code 39 .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.21406), X64 RyuJIT; X.GenericClassWithIntGenericInstanceField()
xor eax,eax
mov edx,[7FFDE321B7AC]
test edx,edx
jle short M00_L01
M00_L00:
mov rcx,22067122C98
mov rcx,[rcx]
mov dword ptr [rcx+0C],1
inc eax
cmp eax,edx
jl short M00_L00
M00_L01:
ret
; Total bytes of code 39 .NET Core 5.0.0 (CoreCLR 5.0.20.25106, CoreFX 5.0.20.25106), X64 RyuJIT; X.GenericClassWithIntGenericInstanceField()
xor eax,eax
mov edx,[7FFDE9D01EE4]
test edx,edx
jle short M00_L01
M00_L00:
mov rcx,1FBD7F82D18
mov rcx,[rcx]
mov dword ptr [rcx+0C],1
inc eax
cmp eax,edx
jl short M00_L00
M00_L01:
ret
; Total bytes of code 39 By adding some otherwise useless code before the benchmark loop I can get all the version to run quickly:
because now the loop body fits into a naturally aligned 32 byte range: .NET Core 5.0.0 (CoreCLR 5.0.20.25106, CoreFX 5.0.20.25106), X64 RyuJIT; X.GenericClassWithIntGenericInstanceField()
7FFDE53F7D60 mov dword ptr [rcx+8],1
7FFDE53F7D67 mov dword ptr [rcx+0C],3E8
7FFDE53F7D6E mov dword ptr [rcx+10],3
7FFDE53F7D75 xor eax,eax
7FFDE53F7D77 mov edx,[7FFDE5401EE4]
7FFDE53F7D7D test edx,edx
7FFDE53F7D7F jle short M00_L01
M00_L00:
7FFDE53F7D81 mov rcx,1E05C132D18
7FFDE53F7D8B mov rcx,[rcx]
7FFDE53F7D8E mov dword ptr [rcx+0C],1
7FFDE53F7D95 inc eax
7FFDE53F7D97 cmp eax,edx
7FFDE53F7D99 jl short M00_L00
M00_L01:
7FFDE53F7D9B ret
; Total bytes of code 60 What's unfortunate here is that the default behavior for 5.0 will "ensure" slow execution by 32 byte aligning the method start, but doing so is a necessary prerequisite to one day perhaps aligning loop tops, as in #8108. I don't see anything actionable here for 5.0. |
We use the default of .Net Core, which I believe is running with tiered jitting on. |
That's a bit puzzling. Any way we can verify this? Do we collect any event logs from the benchmark runs? |
I'm going to close this. We can follow up on why we're still seeing what look like alignment artifacts in the lab data separately. |
There is a 115% regression in PerfLabTests.LowLevelPerf.GenericClassWithIntGenericInstanceField between 3.0->3.1
category:cq
theme:benchmarks
skill-level:intermediate
cost:medium
The text was updated successfully, but these errors were encountered: