String.Replace(char, char) now slower in some cases #74771
Comments
danmoseley
added
area-System.Runtime
tenet-performance
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsMoving discussion from the PR #67049 @gfoidl, at least on my machine, comparing string.Replace in .NET 6 vs .NET 7, multiple examples I've tried have shown .NET 7 to have regressed, e.g. const string Input = """
Whose woods these are I think I know.
His house is in the village though;
He will not see me stopping here
To watch his woods fill up with snow.
My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the year.
He gives his harness bells a shake
To ask if there is some mistake.
The only other sound’s the sweep
Of easy wind and downy flake.
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
""";
[Benchmark]
public string Replace() => Input.Replace('I', 'U');Method Runtime Mean Ratio gfoidl commented yesterday When i duplicate the string.Replace(char, char)-method in order to compare the old and the new implementation both on .NET 7 then I see BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19043.1889 (21H1/May2021Update) Method Mean Error StdDev Median Ratio RatioSD I checked the dasm (via DisassemblyDiagnoser of BDN) and that looks OK. Can this be something from different machine-code layout (loops), PGO, etc. that causes the difference between .NET 6 and .NET 7? @stephentoub @tannergooding This could be related to stale PGO data @danmoseley @danmoseley @stephentoub @danmoseley and got BenchmarkDotNet=v0.13.2, OS=Windows 11 (10.0.22000.856/21H2)
(should we be surprised that disabling PGO didn't make any difference? perhaps it doesn't exercise this method? cc @AndyAyersMS ) @danmoseley
@gfoidl Yes (sorry for slow response, was Sunday...). This is the machine code I get (from BDN) when run @danmoseley's benchmark (.NET 7 only). Left there some comments. ; Program.Replace()
mov rcx,1C003C090A0
mov rcx,[rcx]
mov edx,49
mov r8d,55
jmp qword ptr [7FFEFA7430C0]
; Total bytes of code 30
; System.String.Replace(Char, Char)
push r15
push r14
push rdi
push rsi
push rbp
push rbx
sub rsp,28
vzeroupper
mov rsi,rcx
mov edi,edx
mov ebx,r8d
movzx ecx,di
movzx r8d,bx
cmp ecx,r8d
je near ptr M01_L09
lea rcx,[rsi+0C]
mov r8d,[rsi+8]
movsx rdx,di
call qword ptr [7FFEFA7433C0]
mov ebp,eax
test ebp,ebp
jge short M01_L00
mov rax,rsi ; uncommon case, could jump to M01_L09 instead
vzeroupper
add rsp,28
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
M01_L00:
mov ecx,[rsi+8]
sub ecx,ebp
mov r14d,ecx
mov ecx,[rsi+8]
call System.String.FastAllocateString(Int32)
mov r15,rax
test ebp,ebp
jg near ptr M01_L10 ; should be common path, I don't expect to jump to the end, then back to here
M01_L01:
mov eax,ebp
lea rax,[rsi+rax*2+0C]
cmp [r15],r15b
mov edx,ebp
lea rdx,[r15+rdx*2+0C]
xor ecx,ecx
cmp dword ptr [rsi+8],10
jl near ptr M01_L07
movzx r8d,di
imul r8d,10001 ; this is tracked in https://github.com/dotnet/runtime/issues/67038, .NET 6 has the same issue, so no difference expected
vmovd xmm0,r8d
vpbroadcastd ymm0,xmm0 ; should be vpbroadcastb, see comment above
movzx r8d,bx
imul r8d,10001
vmovd xmm1,r8d
vpbroadcastd ymm1,xmm1 ; vpbroadcastb (see above)
cmp r14,10
jbe short M01_L03
add r14,0FFFFFFFFFFFFFFF0
M01_L02:
lea r8,[rax+rcx*2]
vmovupd ymm2,[r8]
vpcmpeqw ymm3,ymm2,ymm0
vpand ymm4,ymm3,ymm1 ; the vpand, vpandn, vpor series should be vpblendvb, https://github.com/dotnet/runtime/issues/67039 tracked this
vpandn ymm2,ymm3,ymm2 ; the "duplicated code for string.Replace" method emits vpblendvb as expected, but
vpor ymm2,ymm4,ymm2 ; if string.Replace from .NET 7.0.0 (7.0.22.42212) (.NET SDK=7.0.100-rc.2.22426.5) is used, then it's this series
lea r8,[rdx+rcx*2]
vmovupd [r8],ymm2
add rcx,10
cmp rcx,r14
jb short M01_L02
M01_L03:
mov ecx,[rsi+8]
add ecx,0FFFFFFF0
add rsi,0C
lea rsi,[rsi+rcx*2]
vmovupd ymm2,[rsi]
vpcmpeqw ymm3,ymm2,ymm0
vpand ymm0,ymm3,ymm1
vpandn ymm1,ymm3,ymm2
vpor ymm2,ymm0,ymm1
lea rax,[r15+0C]
lea rax,[rax+rcx*2]
vmovupd [rax],ymm2
jmp short M01_L08
M01_L04:
movzx r8d,word ptr [rax+rcx*2]
lea r9,[rdx+rcx*2]
movzx r10d,di
cmp r8d,r10d
je short M01_L05 ; not relevant for .NET 6 -> .NET 7 comparison in this test-case, but
jmp short M01_L06 ; one jump could be avoided?!
M01_L05:
movzx r8d,bx
M01_L06:
mov [r9],r8w
inc rcx
M01_L07:
cmp rcx,r14
jb short M01_L04
M01_L08:
mov rax,r15
vzeroupper
add rsp,28
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
M01_L09: ; expect the mov rax,{r15,rsi} the epilogs are the same, can they be collapsed to
mov rax,rsi ; get less machine code?
vzeroupper
add rsp,28
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
M01_L10: ; this block should be common enough, so should be on the jump-root (see comment above)
cmp [r15],r15b ; it's the Memmove-call
lea rcx,[r15+0C]
lea rdx,[rsi+0C]
mov r8d,ebp
add r8,r8
call qword ptr [7FFEFA7399F0]
jmp near ptr M01_L01
; Total bytes of code 383So from code-layout one major difference to .NET 6 is that the call to System.Buffer.Memmove is moved out of the hot-path. I also wonder why vpblendvb is gone when using string.Replace in the benchmark from .NET-bits. The beginning of the method, right after the prolog, looks different between .NET 6 and .NET 7, although this PR didn't change anything here. I don't expect that this causes the regression, as with the given input the vectorized loop with 33 iterations should be dominant enough (just my feeling, maybe wrong). So far the "static analysis", but I doubt this is enough. Machine code for .NET 6 (for reference) AndyAyersMS commented 2 hours ago Hard to say without looking deeper -- from the .NET 7 code above I would guess PGO is driving the code layout changes. For the .NET 7 you can use DOTNET_JitDIsasm in BDN to obtain the jit disasm which will tell you if there was PGO found (at least for the root method).
|
Given the regression exists with PGO disabled, maybe it isn't critical. @dotnet/jit-contrib can someone on the JIT team comment on @gfoidl 's findings above? We are trying to figure out why there has been a regression in some cases. @stephentoub did you try a variety of tests (length of input and number of hits) and see a general regression? |
We can only disable dynamic PGO (D-PGO), not the static PGO. Correct? |
|
With ; Assembly listing for method String:Replace(ushort,ushort):String:this
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; Tier-1 compilation
; optimized code
; optimized using profile data
; rsp based frame
; fully interruptible
; with Static PGO: edge weights are invalid, and fgCalledCount is 47166
; 1 inlinees with PGO data; 16 single block inlinees; 0 inlinees without PGO dataWhat is the meaning of "edge weights are invalid"? With ; Assembly listing for method String:Replace(ushort,ushort):String:this
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; Tier-1 compilation
; optimized code
; rsp based frame
; fully interruptible
; PGO data available, but JitDisablePgo > 0
; 0 inlinees with PGO data; 16 single block inlinees; 2 inlinees without PGO datafull assembly listing
|
|
@gfoidl you mentioned you see the same regression vs 6.0 on this example, but do you still see the wins in the scenarios you tried while working on the PR -- or did they vanish somehow? @DrewScoggins or @EgorBo can you help point me at recent results for our perf test here? I am not sure how to find them. Specifically I'd like to see what change they saw either side of the PR #67049. @dotnet/jit-contrib do you see anything in the assembly before and after that @gfoidl posted above? including the annotated version higher up. |
DOTNET_JitDisablePGO=1 should disable both. Static PGO specifically can be disabled by simply using DOTNET_ReadyToRun=0
Nvm, it's just a sign that JIT made some mistakes calculating edges' weights - it happens in many cases.
Here is the link: https://pvscmdupload.blob.core.windows.net/reports/allTestHistory/TestHistoryIndexIndex.html |
While working on the PR I duplicated the code of When I use the benchmark from your gist (.NET 6 vs .NET 7 and the bits provided by the SDK installer) with different input-strings (kind of manual random exploration) it seems like this is really weird. With the same inputs and the duplicated code (the benchmark run to compare old and new version of code with .NET 7) the new version is faster. |
|
Bearing in mind the change went in on Aug 16. Some scenarios show no change (but a regression earlier in the month) Some show a big improvement Some a regression Not sure whether you can access these files @gfoidl I'm assuming not (and if not ideally we would fix that) |
This is curious .. what could cause the standalone to be faster, but in the product slower .. especially if PGO is disabled... code alignment? |
|
Yes I can access these files. It's also interesting that arm64 / ubuntu 20.04 shows improvements, e.g. Wasm (when I interpret "CompilationMode=wasm,RunKind=micro" correct) shows a regression, and I assume that wasm doesn't support vectors (or does it).
This is my bet. Some results in the charts look unstable -- which might be from alignment (amongst others). What bothers me is that with the duplicated code the theory of "processing the remaining elements in one vectorized pass is faster" is confirmed. But with the shipped bits it is not clear, rather it regresses. |
|
@AndyAyersMS @kunalspathak is there some way we can help determine whether it is an alignment issue? |
The perf history should be visible by anyone.
For code alignment you can (with suitable checked jit) also set Give we're dealing with strings. data alignment may also play a role. You might try rerunning the BDN results with increased numbers of measurement intervals and memory randomization ( |
|
Running the benchmarks with What's a "with suitable checked jit"? The checked build with one can get the JIS-dasm? What else can I do to move forward here? |
In both .NET 6 and .NET 7, the vectorized loop is not aligned and I don't see any JCC erratum coming in the way in those loop.s .NET 6 code; Assembly listing for method System.String:Replace(ushort,ushort):System.String:this
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; optimized code
; rsp based frame
; fully interruptible
; Final local variable assignments
;
; V00 this [V00,T08] ( 6, 4 ) ref -> rsi this class-hnd single-def
; V01 arg1 [V01,T09] ( 3, 3 ) ushort -> rdx single-def
; V02 arg2 [V02,T10] ( 3, 3 ) ushort -> r8 single-def
; V03 loc0 [V03,T14] ( 4, 2 ) int -> r15
; V04 loc1 [V04,T00] ( 9, 25.50) int -> rsi
; V05 loc2 [V05,T12] ( 6, 3 ) ref -> r14 class-hnd single-def
; V06 loc3 [V06,T15] ( 4, 2 ) int -> r15
; V07 loc4 [V07,T01] ( 7, 24.50) byref -> rbp
; V08 loc5 [V08,T02] ( 7, 24.50) byref -> rdx
; V09 loc6 [V09,T26] ( 2, 4.50) simd32 -> mm0 ld-addr-op
; V10 loc7 [V10,T27] ( 2, 4.50) simd32 -> mm1 ld-addr-op
; V11 loc8 [V11,T23] ( 3, 12 ) simd32 -> mm2
; V12 loc9 [V12,T24] ( 3, 12 ) simd32 -> mm3
; V13 loc10 [V13,T25] ( 2, 8 ) simd32 -> mm2
; V14 loc11 [V14,T03] ( 3, 10 ) ushort -> rax
; V15 OutArgs [V15 ] ( 1, 1 ) lclBlk (32) [rsp+00H] "OutgoingArgSpace"
; V16 tmp1 [V16,T04] ( 3, 8 ) byref -> rcx
; V17 tmp2 [V17,T05] ( 3, 8 ) byref -> rcx
; V18 tmp3 [V18,T06] ( 3, 8 ) int -> rax
; V19 tmp4 [V19,T17] ( 2, 2 ) byref -> rcx single-def "Inlining Arg"
; V20 tmp5 [V20,T18] ( 2, 2 ) byref -> rdx single-def "Inlining Arg"
;* V21 tmp6 [V21 ] ( 0, 0 ) byref -> zero-ref "impAppendStmt"
; V22 tmp7 [V22,T21] ( 2, 2 ) long -> r8 "Inlining Arg"
;* V23 tmp8 [V23 ] ( 0, 0 ) byref -> zero-ref "impAppendStmt"
;* V24 tmp9 [V24 ] ( 0, 0 ) byref -> zero-ref single-def "impAppendStmt"
;* V25 tmp10 [V25 ] ( 0, 0 ) byref -> zero-ref single-def "impAppendStmt"
;* V26 tmp11 [V26 ] ( 0, 0 ) long -> zero-ref "Inlining Arg"
; V27 tmp12 [V27,T19] ( 2, 2 ) byref -> rbp single-def "Inlining Arg"
; V28 tmp13 [V28,T20] ( 2, 2 ) byref -> rdx single-def "Inlining Arg"
;* V29 tmp14 [V29 ] ( 0, 0 ) simd32 -> zero-ref "Inlining Arg"
; V30 cse0 [V30,T22] ( 3, 1.50) long -> rax "CSE - moderate"
; V31 cse1 [V31,T07] ( 5, 7 ) int -> rdi "CSE - aggressive"
; V32 cse2 [V32,T11] ( 4, 4.50) int -> rbx "CSE - moderate"
; V33 cse3 [V33,T16] ( 4, 2 ) int -> r14 "CSE - moderate"
; V34 cse4 [V34,T13] ( 4, 2 ) byref -> rbp "CSE - moderate"
;
; Lcl frame size = 40
G_M34983_IG01:
push r15
push r14
push rdi
push rsi
push rbp
push rbx
sub rsp, 40
vzeroupper
mov rsi, rcx
;; bbWeight=1 PerfScore 7.50
G_M34983_IG02:
movzx rdi, dx
movzx rbx, r8w
cmp edi, ebx
jne SHORT G_M34983_IG05
;; bbWeight=1 PerfScore 1.75
G_M34983_IG03:
mov rax, rsi
; ............................... 32B boundary ...............................
;; bbWeight=0.50 PerfScore 0.12
G_M34983_IG04:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
;; bbWeight=0.50 PerfScore 2.62
G_M34983_IG05:
lea rbp, bword ptr [rsi+12]
mov rcx, rbp
mov r14d, dword ptr [rsi+8]
mov r8d, r14d
mov edx, edi
; ............................... 32B boundary ...............................
call System.SpanHelpers:IndexOf(byref,ushort,int):int
mov r15d, eax
test r15d, r15d
jge SHORT G_M34983_IG07
mov rax, rsi
;; bbWeight=0.50 PerfScore 3.00
G_M34983_IG06:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (ret: 0 ; jcc erratum) 32B boundary ...............................
;; bbWeight=0.50 PerfScore 2.62
G_M34983_IG07:
mov esi, r14d
sub esi, r15d
mov ecx, r14d
call System.String:FastAllocateString(int):System.String
mov r14, rax
test r15d, r15d
jle SHORT G_M34983_IG08
cmp dword ptr [r14], r14d
lea rcx, bword ptr [r14+12]
mov rdx, rbp
; ............................... 32B boundary ...............................
mov r8d, r15d
add r8, r8
call System.Buffer:Memmove(byref,byref,long)
;; bbWeight=0.50 PerfScore 3.75
G_M34983_IG08:
movsxd rax, r15d
add rax, rax
add rbp, rax
cmp dword ptr [r14], r14d
lea rdx, bword ptr [r14+12]
add rdx, rax
cmp esi, 16
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (cmp: 1 ; jcc erratum) 32B boundary ...............................
jl SHORT G_M34983_IG10
imul eax, edi, 0x10001
vmovd xmm0, eax
vpbroadcastd ymm0, ymm0
imul eax, ebx, 0x10001
vmovd xmm1, eax
vpbroadcastd ymm1, ymm1
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (vpbroadcastd: 3) 32B boundary ...............................
align [0 bytes]
;; bbWeight=0.50 PerfScore 8.38
G_M34983_IG09:
vmovupd ymm2, ymmword ptr[rbp]
vpcmpeqw ymm3, ymm2, ymm0
vpand ymm4, ymm1, ymm3
vpandn ymm2, ymm3, ymm2
vpor ymm2, ymm4, ymm2
vmovupd ymmword ptr[rdx], ymm2
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (vmovupd: 2) 32B boundary ...............................
add rbp, 32
add rdx, 32
add esi, -16
cmp esi, 16
jge SHORT G_M34983_IG09
;; bbWeight=4 PerfScore 42.00
G_M34983_IG10:
test esi, esi
jle SHORT G_M34983_IG15
align [10 bytes]
; ............................... 32B boundary ...............................
;; bbWeight=0.50 PerfScore 0.75
G_M34983_IG11:
movzx rax, word ptr [rbp]
mov rcx, rdx
cmp eax, edi
je SHORT G_M34983_IG13
;; bbWeight=4 PerfScore 14.00
G_M34983_IG12:
jmp SHORT G_M34983_IG14
;; bbWeight=2 PerfScore 4.00
G_M34983_IG13:
mov eax, ebx
;; bbWeight=2 PerfScore 0.50
G_M34983_IG14:
mov word ptr [rcx], ax
add rbp, 2
add rdx, 2
dec esi
test esi, esi
jg SHORT G_M34983_IG11
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (jg: 0 ; jcc erratum) 32B boundary ...............................
;; bbWeight=4 PerfScore 12.00
G_M34983_IG15:
mov rax, r14
;; bbWeight=0.50 PerfScore 0.12
G_M34983_IG16:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
;; bbWeight=0.50 PerfScore 2.62
; Total bytes of code 307, prolog size 18, PerfScore 136.45, instruction count 106, allocated bytes for code 307 (MethodHash=695a7758) for method System.String:Replace(ushort,ushort):System.String:this
; ============================================================
.NET 7 code; Assembly listing for method System.String:Replace(ushort,ushort):System.String:this
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; Tier-1 compilation
; optimized code
; optimized using profile data
; rsp based frame
; fully interruptible
; with Static PGO: edge weights are invalid, and fgCalledCount is 47166
; 1 inlinees with PGO data; 16 single block inlinees; 0 inlinees without PGO data
; Final local variable assignments
;
; V00 this [V00,T00] ( 13, 5.10) ref -> rsi this class-hnd single-def
; V01 arg1 [V01,T01] ( 6, 4.00) ushort -> rdi single-def
; V02 arg2 [V02,T02] ( 5, 3 ) ushort -> rbx single-def
; V03 loc0 [V03,T03] ( 4, 2.21) int -> rbp
; V04 loc1 [V04,T06] ( 4, 0.10) long -> r14
; V05 loc2 [V05,T05] ( 7, 0.10) ref -> r15 class-hnd single-def
; V06 loc3 [V06,T04] ( 5, 0.21) int -> rbp
; V07 loc4 [V07,T13] ( 3, 0 ) byref -> rax single-def
; V08 loc5 [V08,T14] ( 3, 0 ) byref -> rdx single-def
; V09 loc6 [V09,T07] ( 14, 0 ) long -> rcx
; V10 loc7 [V10,T17] ( 3, 0 ) simd32 -> mm0 ld-addr-op
; V11 loc8 [V11,T18] ( 3, 0 ) simd32 -> mm1 ld-addr-op
; V12 loc9 [V12,T08] ( 6, 0 ) simd32 -> mm2
; V13 loc10 [V13,T09] ( 6, 0 ) simd32 -> mm3
; V14 loc11 [V14,T12] ( 4, 0 ) simd32 -> mm2
; V15 loc12 [V15,T25] ( 2, 0 ) long -> r14
; V16 loc13 [V16,T19] ( 3, 0 ) ushort -> r8
; V17 OutArgs [V17 ] ( 1, 1 ) lclBlk (32) [rsp+00H] "OutgoingArgSpace"
; V18 tmp1 [V18,T15] ( 3, 0 ) byref -> r9
; V19 tmp2 [V19,T16] ( 3, 0 ) byref -> r9
; V20 tmp3 [V20,T20] ( 3, 0 ) int -> r8
;* V21 tmp4 [V21 ] ( 0, 0 ) byref -> zero-ref "Inlining Arg"
;* V22 tmp5 [V22 ] ( 0, 0 ) int -> zero-ref "Inlining Arg"
;* V23 tmp6 [V23 ] ( 0, 0 ) short -> zero-ref "Inlining Arg"
; V24 tmp7 [V24,T21] ( 2, 0 ) byref -> rcx single-def "Inlining Arg"
; V25 tmp8 [V25,T22] ( 2, 0 ) byref -> rdx single-def "Inlining Arg"
; V26 tmp9 [V26,T26] ( 2, 0 ) long -> r8 "Inlining Arg"
; V27 tmp10 [V27,T23] ( 2, 0 ) byref -> r8 "Inlining Arg"
; V28 tmp11 [V28,T24] ( 2, 0 ) byref -> r8 "Inlining Arg"
;* V29 tmp12 [V29 ] ( 0, 0 ) simd32 -> zero-ref "Inlining Arg"
;* V30 tmp13 [V30 ] ( 0, 0 ) simd32 -> zero-ref "Inlining Arg"
; V31 tmp14 [V31,T10] ( 4, 0 ) byref -> rsi "Inlining Arg"
; V32 tmp15 [V32,T11] ( 4, 0 ) byref -> rax "Inlining Arg"
;* V33 tmp16 [V33 ] ( 0, 0 ) simd32 -> zero-ref "Inlining Arg"
;* V34 tmp17 [V34 ] ( 0, 0 ) simd32 -> zero-ref "Inlining Arg"
;
; Lcl frame size = 40
G_M34983_IG01:
push r15
push r14
push rdi
push rsi
push rbp
push rbx
sub rsp, 40
vzeroupper
mov rsi, rcx
mov edi, edx
mov ebx, r8d
;; size=23 bbWeight=1 PerfScore 8.00
G_M34983_IG02:
movzx rcx, di
movzx r8, bx
cmp ecx, r8d
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (cmp: 1 ; jcc erratum) 32B boundary ...............................
je G_M34983_IG16
;; size=16 bbWeight=1 PerfScore 1.75
G_M34983_IG03:
lea rcx, bword ptr [rsi+0CH]
mov r8d, dword ptr [rsi+08H]
movsx rdx, di
call [System.SpanHelpers:IndexOfValueType(byref,short,int):int]
mov ebp, eax
test ebp, ebp
jge SHORT G_M34983_IG06
;; size=24 bbWeight=1.00 PerfScore 7.25
G_M34983_IG04:
mov rax, rsi
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (mov: 2) 32B boundary ...............................
;; size=3 bbWeight=0.90 PerfScore 0.22
G_M34983_IG05:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
;; size=16 bbWeight=0.90 PerfScore 4.71
G_M34983_IG06:
mov ecx, dword ptr [rsi+08H]
sub ecx, ebp
mov r14d, ecx
mov ecx, dword ptr [rsi+08H]
call System.String:FastAllocateString(int):System.String
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (call: 2 ; jcc erratum) 32B boundary ...............................
mov r15, rax
test ebp, ebp
jg G_M34983_IG18
;; size=27 bbWeight=0.10 PerfScore 0.72
G_M34983_IG07:
mov eax, ebp
lea rax, bword ptr [rsi+2*rax+0CH]
cmp byte ptr [r15], r15b
mov edx, ebp
lea rdx, bword ptr [r15+2*rdx+0CH]
xor ecx, ecx
; ............................... 32B boundary ...............................
cmp dword ptr [rsi+08H], 16
jl G_M34983_IG13
movzx r8, di
imul r8d, r8d, 0x10001
vmovd xmm0, r8d
vpbroadcastd ymm0, ymm0
movzx r8, bx
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (movzx: 3) 32B boundary ...............................
imul r8d, r8d, 0x10001
vmovd xmm1, r8d
vpbroadcastd ymm1, ymm1
cmp r14, 16
jbe SHORT G_M34983_IG09
add r14, -16
;; size=81 bbWeight=0 PerfScore 0.00
G_M34983_IG08:
lea r8, bword ptr [rax+2*rcx]
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (lea: 2) 32B boundary ...............................
vmovupd ymm2, ymmword ptr[r8]
vpcmpeqw ymm3, ymm2, ymm0
vpand ymm4, ymm3, ymm1
vpandn ymm2, ymm3, ymm2
vpor ymm2, ymm4, ymm2
lea r8, bword ptr [rdx+2*rcx]
vmovupd ymmword ptr[r8], ymm2
; ............................... 32B boundary ...............................
add rcx, 16
cmp rcx, r14
jb SHORT G_M34983_IG08
;; size=43 bbWeight=0 PerfScore 0.00
G_M34983_IG09:
mov ecx, dword ptr [rsi+08H]
add ecx, -16
add rsi, 12
lea rsi, bword ptr [rsi+2*rcx]
vmovupd ymm2, ymmword ptr[rsi]
vpcmpeqw ymm3, ymm2, ymm0
vpand ymm0, ymm3, ymm1
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (vpand: 3) 32B boundary ...............................
vpandn ymm1, ymm3, ymm2
vpor ymm2, ymm0, ymm1
lea rax, bword ptr [r15+0CH]
lea rax, bword ptr [rax+2*rcx]
vmovupd ymmword ptr[rax], ymm2
jmp SHORT G_M34983_IG14
;; size=48 bbWeight=0 PerfScore 0.00
G_M34983_IG10:
movzx r8, word ptr [rax+2*rcx]
lea r9, bword ptr [rdx+2*rcx]
; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (lea: 2) 32B boundary ...............................
movzx r10, di
cmp r8d, r10d
je SHORT G_M34983_IG11
jmp SHORT G_M34983_IG12
;; size=20 bbWeight=0 PerfScore 0.00
G_M34983_IG11:
movzx r8, bx
;; size=4 bbWeight=0 PerfScore 0.00
G_M34983_IG12:
mov word ptr [r9], r8w
inc rcx
;; size=7 bbWeight=0 PerfScore 0.00
G_M34983_IG13:
cmp rcx, r14
jb SHORT G_M34983_IG10
;; size=5 bbWeight=0 PerfScore 0.00
G_M34983_IG14:
mov rax, r15
; ............................... 32B boundary ...............................
;; size=3 bbWeight=0 PerfScore 0.00
G_M34983_IG15:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
pop r15
ret
;; size=16 bbWeight=0 PerfScore 0.00
G_M34983_IG16:
mov rax, rsi
;; size=3 bbWeight=0 PerfScore 0.00
G_M34983_IG17:
vzeroupper
add rsp, 40
pop rbx
pop rbp
pop rsi
pop rdi
pop r14
; ............................... 32B boundary ...............................
pop r15
ret
;; size=16 bbWeight=0 PerfScore 0.00
G_M34983_IG18:
cmp byte ptr [r15], r15b
lea rcx, bword ptr [r15+0CH]
lea rdx, bword ptr [rsi+0CH]
mov r8d, ebp
add r8, r8
call [System.Buffer:Memmove(byref,byref,long)]
jmp G_M34983_IG07
;; size=28 bbWeight=0 PerfScore 0.00One thing that I noticed is in .NET 6, |
Is there an environment variable to try that would force it to be optimized? Although, I thought BDN defeats tiering. |
I did try |
|
I believe @stephentoub you said that you'd tried various scenarios (lengths, position of hits if any) and it was slower in general. So this is not a case of "are the improvements worth the regressions" -- we have to either fix the regression or revert this change for 7.0 to get back to a known state. Given the schedule, we need to do one or the other by the end of the week. Is there a clear next step for investigation, or should we revert or 7.0? We can continue working on the problem in order to have the change in 8.0 |
|
I spent a bit more time running various tests. I suspect this is actually not related to the Replace PR and instead related more to something allocation-related, like regions in .NET 7. I see comparable regressions with these: const string Input = """
Whose woods these are I think I know.
His house is in the village though;
He will not see me stopping here
To watch his woods fill up with snow.
My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the year.
He gives his harness bells a shake
To ask if there is some mistake.
The only other sound’s the sweep
Of easy wind and downy flake.
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
""";
private char[] _chars = Input.ToCharArray();
[Benchmark]
public string WithContent1() => new string(_chars);
[Benchmark]
public string WithContent2() => string.Create(Input.Length, Input, (dest, state) => state.AsSpan().CopyTo(dest));
[Benchmark]
public string WithoutContent1() => string.Create(Input.Length, Input, (dest, state) => { });
[Benchmark]
public string WithoutContent2() => new string('\0', Input.Length);
|
|
Does disabling GC regions help? |
Latest RC2:
Latest RC2 w/ DOTNET_GCName="clrgc.dll"
@mangod9, is this expected? |
|
some of similar smaller microbenchmarks have regressed based on GC writer barrier work. Please see: #74014. @PeterSolMS has investigated and determined that the write barrier work should help with most real world workloads. Does @dotnet/gc |
|
Figured this was a good opportunity to make use of the new tooling we created during quality week that automates running microbenchmarks and generates comparative results. (CC: @dotnet/gc) SummaryI was able to repro this regression locally (.NET7 execution time is much higher than that of .NET6 for longer strings) where I ran all microbenchmarks matching the filter
The main observation was that there was not a significant enough difference after setting COMPlus_GCWriteBarrier=3 and COMPlus_EnableWriteXorExecute=0 and therefore, we regressed by ~7.5% for .NET 7 in comparison to .NET 6 for Also, we didn't observe the regression for this large string for segments implying that this microbenchmark regressed once we enabled regions (full details below); unfortunately, the trend for this microbenchmark doesn't go back to before we enabled regions:
Full Automated ReportSummaryMicrobenchmarks Considered:
Large Regressions (>20%)
Large Improvements (>20%)
Regressions (5% - 20%)
Improvements (5% - 20%)
Stale (Same or percent difference within 5% margin)
|
Not really, in fact on its own it seems to mostly make it worse. DOTNET_GCName="clrgc.dll" to disable regions consistently improves things:
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Environments;
using BenchmarkDotNet.Jobs;
using BenchmarkDotNet.Running;
using System;
[Config(typeof(ConfigWithCustomEnvVars))]
public partial class Program
{
static void Main(string[] args) => BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly).Run(args);
private sealed class ConfigWithCustomEnvVars : ManualConfig
{
public ConfigWithCustomEnvVars()
{
AddJob(Job.Default.WithRuntime(CoreRuntime.Core70).AsBaseline());
AddJob(Job.Default.WithRuntime(CoreRuntime.Core70).WithEnvironmentVariables(new EnvironmentVariable("DOTNET_GCName", "clrgc.dll")));
AddJob(Job.Default.WithRuntime(CoreRuntime.Core70).WithEnvironmentVariables(new EnvironmentVariable("COMPLUS_GCWriteBarrier", "3")));
AddJob(Job.Default.WithRuntime(CoreRuntime.Core70).WithEnvironmentVariables(new EnvironmentVariable("DOTNET_GCName", "clrgc.dll"), new EnvironmentVariable("COMPLUS_GCWriteBarrier", "3")));
}
}
const string Input = """
Whose woods these are I think I know.
His house is in the village though;
He will not see me stopping here
To watch his woods fill up with snow.
My little horse must think it queer
To stop without a farmhouse near
Between the woods and frozen lake
The darkest evening of the year.
He gives his harness bells a shake
To ask if there is some mistake.
The only other sound’s the sweep
Of easy wind and downy flake.
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
""";
private char[] _chars = Input.ToCharArray();
[Benchmark]
public string WithContent1() => new string(_chars);
[Benchmark]
public string WithContent2() => string.Create(Input.Length, Input, (dest, state) => state.AsSpan().CopyTo(dest));
[Benchmark]
public string WithoutContent1() => string.Create(Input.Length, Input, (dest, state) => { });
[Benchmark]
public string WithoutContent2() => new string('\0', Input.Length);
} |
|
Repeated the
Next steps: We are tracking decommit issues here: #73592 and since the diagnosis of this regression is perceivably linked to that issue that @PeterSolMS is currently working on fixing, I'm moving the milestone to 8.0; Please let me know if that's an incorrect follow-up. CC: @dotnet/gc Data / DetailsComparisons
Individual ResultsBaseline: SegmentsOutlierMode=DontRemove EnvironmentVariables=COMPlus_GCName=clrgc.dll PowerPlanMode=00000000-0000-0000-0000-000000000000
RegionsOutlierMode=DontRemove PowerPlanMode=00000000-0000-0000-0000-000000000000 Force=False
Regions w/ A More Precise Write BarrierOutlierMode=DontRemove EnvironmentVariables=COMPlus_GCWriteBarrier=3,COMPlus_EnableWriteXorExecute=0 PowerPlanMode=00000000-0000-0000-0000-000000000000
|
@mrsharm the latest data comparing 6.0 to 7.0 (with standard settings) seems to show significant regressions. I don't think we want to willingly ship with these regressions. I think we need to keep this in .NET 7 milestone and the GC path, one way or another. Given we don't want to regress, are these our options for .NET 7?
|
What change? The most recent benchmark examples aren't using Replace. |
|
this should be investigated to understand what exactly is causing the regression before we move the milestone to 8.0. last time I was going to investigate these regressions with Moko we discovered that BDN was doing things very differently between 2 runs so he's been focusing on making the runs repeatable. so I'm going to take another look again with him. |
Ah, I didn't see that. Scratch that option then. So we should either confirm it's not something real code would see, or find a fix. |
|
Others are noticing this as well, e.g. |
|
We have been working through root-causing and fixing this issue and here are our conclusions:
Any thoughts / concerns here? Results
Details
Full comparison table with the virtual commit and decommit data: Compare.xlsx CC: @dotnet/gc |
|
Thanks for the analysis @mrsharm. If the overall regression < 5% with the decommit fix we should be able to make further improvements in 8. @stephentoub would you agree? |
10% can be a lot, so it seems important to know what customers will see and where. |
The common symptoms are higher virtual commits and decommits - both in terms of bytes and the number of calls. We are tracking all other regressed benchmarks with the same root cause here: #73592
Other members of @dotnet/gc can chime in here for more details however, we do believe that we are doing better for actual customer scenarios based on our perf testing. Additionally, we do believe that prospective updates will improve GC pause times even further. |
|
correct, the current fix is for wks, but @PeterSolMS @Maoni0 are working on a change for svr. @stephentoub, assume you observe regression for wks as well, or is it with svr only? |
I'd only measured with server. |
|
we didn't try the server GC fix on these since we didn't know you were running this with Server GC. how many heaps are you running this with? would it be possible that you could take a GCCollectOnly trace when you running it? perfview /nogui /accepteula /GCCollectOnly collect test.etl |
This is on a 12 logical core, so I assume 12 (I've not overridden any defaults, other than having using System.Diagnostics;
using System.Runtime;
internal class Program
{
static void Main()
{
Console.WriteLine($"IsServerGC: {GCSettings.IsServerGC}");
var sw = new Stopwatch();
for (int trials = 0; trials < 10; trials++)
{
sw.Restart();
for (int i = 0; i < 100_000_000; i++)
{
_ = new string('\0', 256);
}
sw.Stop();
Console.WriteLine(sw.Elapsed.TotalMilliseconds);
}
}
}outputs the following on .NET 6: IsServerGC: True
3541.6588
3853.6238
3792.7101
3909.1076
3854.9526
3445.2005
3344.1826
3343.1901
3331.0722
3410.051and the following on .NET 7: IsServerGC: True
4627.28
4488.4879
4512.589
4499.0618
5184.8121
4649.4892
4735.7333
4693.8634
4869.3155
4920.06(obviously times vary a bit from run to run, but the relative size of the gap remains). I can send you a GCCollectOnly trace if you can't repro it. I assumed from all of the comments from @mrsharm earlier that it was easily reproed. |
he never attempted to repro it with server GC since none of us knew you ran this with server GC :) and this is a very unusual scenario for running server GC with (we don't run microbenchmarks with server gc because they are in general tiny things). but yes, we could repro it after we tried it so we don't need a trace. |
Except for specific scenarios that demand otherwise, I always benchmark with server GC, since that's the default ASP.NET configuration. |
|
keep in mind that asp.net does not do all these induced GCs - these induced GCs that BDN does can dramatically change the memory perf behavior. |
|
It's why I also replicate findings without benchmarkdotnet, e.g. in the simple console app shown earlier where there aren't any GC.Collect calls. |
|
so I took a look at the test @stephentoub had running in BDN and standalone. the reasons for the regression is very different. for the BDN scenario we are simply doing a ton of decommitting with regions because BDN induced a lot of gen2 blocking GCs which meant we often got a new gen1 region that's fully committed so we ended up always decommitting the end of it. so it's more an artifact of running BDN. for the standalone case we do a bit of decommitting, the major regression comes from memset costing more. Peter attempted a fix for it but we don't understand the microarchitectural effect what we are seeing there for me to be comfortable to merge it. and the fix makes the segment case improve just as much so regions is not better off :D I'm also seeing higher GC cost but this could totally be due to the fact it's a microbenchmark. I'm not so worried about this because we already validated the GC part a bunch. the summary is we are not trying to get anything in for this this week. we might try to get something in next week if we understand the microarchitectural issue but the likelihood is we'll make some fixes with the 1st servicing release. |
|
removing release-blocking tag, we will possibly consider for servicing |
|
We have improved the microbenchmark numbers for a number of benchmarks in NET 8 and are tracking: #73592 Closing this issue as we are tracking this with the aforementioned issue. |
ghost
locked as resolved and limited conversation to collaborators
Moving discussion from the PR #67049
@gfoidl, at least on my machine, comparing string.Replace in .NET 6 vs .NET 7, multiple examples I've tried have shown .NET 7 to have regressed, e.g.
Method Runtime Mean Ratio
Replace .NET 6.0 108.1 ns 1.00
Replace .NET 7.0 136.0 ns 1.26
Do you see otherwise?
@gfoidl
gfoidl commented yesterday
Hm, that is not expected...
When i duplicate the string.Replace(char, char)-method in order to compare the old and the new implementation both on .NET 7 then I see
BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19043.1889 (21H1/May2021Update)
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET SDK=7.0.100-preview.7.22377.5
[Host] : .NET 7.0.0 (7.0.22.37506), X64 RyuJIT
DefaultJob : .NET 7.0.0 (7.0.22.37506), X64 RyuJIT
Method Mean Error StdDev Median Ratio RatioSD
Default 142.0 ns 3.48 ns 9.98 ns 138.6 ns 1.00 0.00
PR 132.9 ns 2.68 ns 3.40 ns 132.8 ns 0.92 0.07
so a result I'd expect, as after the vectorized loop 6 chars are remaining that the old-code processes in the for-loop whilst the new-code does one vectorized pass.
I checked the dasm (via DisassemblyDiagnoser of BDN) and that looks OK.
Can this be something from different machine-code layout (loops), PGO, etc. that causes the difference between .NET 6 and .NET 7?
How can I investigate this further -- need some guidance on how to check code-layout please.
@stephentoub
stephentoub commented yesterday •
Thanks, @gfoidl. Do you see a similar 6 vs 7 difference as I do? (It might not be specific to this PR.) @EgorBo, can you advise?
@tannergooding
tannergooding commented yesterday
When i duplicate the string.Replace(char, char)-method in order to compare the old and the new implementation both on .NET 7 then I see
This could be related to stale PGO data
@danmoseley
danmoseley commented yesterday
Is there POGO data en-route that has trained with this change in place? I am not sure how to follow it.
@danmoseley
danmoseley commented yesterday
Also, it wouldn't matter here, but are we consuming POGO data trained on main bits in the release branches?
@stephentoub
stephentoub commented yesterday •
I don't think this particular case is related to stale PGO data. I set COMPlus_JitDisablePGO=1, and I still see an ~20% regression from .NET 6 to .NET 7.
@danmoseley
danmoseley commented 21 hours ago •
I ran the example above with
and got
BenchmarkDotNet=v0.13.2, OS=Windows 11 (10.0.22000.856/21H2)
Intel Core i7-10510U CPU 1.80GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK=7.0.100-rc.2.22426.5
[Host] : .NET 7.0.0 (7.0.22.42212), X64 RyuJIT AVX2
Job-DGTURM : .NET 6.0.8 (6.0.822.36306), X64 RyuJIT AVX2
Job-PYGDYG : .NET 7.0.0 (7.0.22.42212), X64 RyuJIT AVX2
Job-ZEPFOF : .NET Core 3.1.28 (CoreCLR 4.700.22.36202, CoreFX 4.700.22.36301), X64 RyuJIT AVX2
Job-PSEWWK : .NET Framework 4.8 (4.8.4510.0), X64 RyuJIT VectorSize=256
Job-WGVIGL : .NET 6.0.8 (6.0.822.36306), X64 RyuJIT AVX2
Job-HBSVYM : .NET 7.0.0 (7.0.22.42212), X64 RyuJIT AVX2
Job-VWWZUC : .NET Core 3.1.28 (CoreCLR 4.700.22.36202, CoreFX 4.700.22.36301), X64 RyuJIT AVX2
Job-LDCOEC : .NET Framework 4.8 (4.8.4510.0), X64 RyuJIT VectorSize=256
(should we be surprised that disabling PGO didn't make any difference? perhaps it doesn't exercise this method? cc @AndyAyersMS )
@danmoseley
danmoseley commented 21 hours ago
and just for interest
@gfoidl
gfoidl commented 9 hours ago
Do you see a similar 6 vs 7 difference as I do?
Yes (sorry for slow response, was Sunday...).
@danmoseley thanks for your numbers.
This is the machine code I get (from BDN) when run @danmoseley's benchmark (.NET 7 only). Left there some comments.
So from code-layout one major difference to .NET 6 is that the call to System.Buffer.Memmove is moved out of the hot-path.
But I doubt that this allone is the cause for the regression.
I also wonder why vpblendvb is gone when using string.Replace in the benchmark from .NET-bits.
If I use a string.Replace-duplicated code for the benchmark, then it's emitted which is what I expect as 10d8a36 got merged on 2022-05-25.
But that shouldn't cause the regression either, as for .NET 6 the same series of vector-instruction are emitted.
The beginning of the method, right after the prolog, looks different between .NET 6 and .NET 7, although this PR didn't change anything here. I don't expect that this causes the regression, as with the given input the vectorized loop with 33 iterations should be dominant enough (just my feeling, maybe wrong).
So far the "static analysis", but I doubt this is enough.
With Intel VTune I see some results, but with my interpretation the conclusions are just the same as stated in this comment.
I hope some JIT experts can shed some light on this (and give some advices on how to investigate, as I'm eager to learn).
Machine code for .NET 6 (for reference)
@AndyAyersMS
AndyAyersMS commented 2 hours ago
(should we be surprised that disabling PGO didn't make any difference? perhaps it doesn't exercise this method? cc @AndyAyersMS )
Hard to say without looking deeper -- from the .NET 7 code above I would guess PGO is driving the code layout changes.
For the .NET 7 you can use DOTNET_JitDIsasm in BDN to obtain the jit disasm which will tell you if there was PGO found (at least for the root method).
The text was updated successfully, but these errors were encountered: