Vectorized code in loop performance problems due to excessive stack <-> vector register moves

[MadProbe]

Description

I am creating an implementation of adler32 checksum using C# and I am getting significant performance regression in comparison with implementation written in rust - simd-adler32 by nearly 2.5 times.
benchmark repository with source code

Configuration

See benchmark results

Regression?

Reproducible in .NET 7.0.

Data

BenchmarkDotNet=v0.13.5, OS=Windows 10 (10.0.19043.2251/21H1/May2021Update)
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET SDK=8.0.100-preview.3.23178.7
  [Host]     : .NET 8.0.0 (8.0.23.17408), X64 RyuJIT AVX2
  DefaultJob : .NET 8.0.0 (8.0.23.17408), X64 RyuJIT AVX2


|     Method |         data |       Mean |     Error |    StdDev | Ratio | Code Size |
|----------- |------------- |-----------:|----------:|----------:|------:|----------:|
| Vectorized | Byte[102400] |   8.366 us | 0.0691 us | 0.0646 us |  0.02 |     902 B |
|      Naive | Byte[102400] | 412.368 us | 2.9653 us | 2.7738 us |  1.00 |     215 B |

adler32 simd implementation written in rust benchmark for avx2 using criterion.rs:

avx2/random-100k        time:   [3.5483 us 3.5684 us 3.5922 us]
                        thrpt:  [25.926 GiB/s 26.099 GiB/s 26.247 GiB/s]
--- some stuff is skipped
avx2/random-100k        time:   [3.5438 us 3.5655 us 3.5892 us]
                        thrpt:  [25.948 GiB/s 26.121 GiB/s 26.280 GiB/s]
                 change:
                        time:   [-1.5116% +0.2112% +2.0511%] (p = 0.82 > 0.05)
                        thrpt:  [-2.0099% -0.2107% +1.5348%]
                        No change in performance detected.

Analysis

Comparing disassemblied code for rust and my c# implementation, the main problem lies in computation loop: there are too much memory <-> vector moves there and it can be much more efficient if more YMM registers were used:

My C# code disassembly:

--- omitted for brevity
M00_L01:
       vmovups   ymm1,[rcx]
       vmovups   ymm2,[r10]
       vpaddq    ymm2,ymm2,[r8]
       vmovups   [r10],ymm2
       vpmaddubsw ymm2,ymm1,ymm0
       vpmaddwd  ymm2,ymm2,[7FFBA0BC7820]
       vpaddd    ymm2,ymm2,[r9]
       vmovups   [r9],ymm2
       vxorps    ymm2,ymm2,ymm2
       vpsadbw   ymm1,ymm1,ymm2
       vpaddq    ymm1,ymm1,[r8]
       vmovups   [r8],ymm1
       add       rcx,20
       cmp       rcx,r11
       jb        short M00_L01
--- omitted for brevity

And rust code loop:
source: https://github.com/mcountryman/simd-adler32/blob/main/src/imp/avx2.rs#L123-L132

--- Decompiled using Ghidra
                             LAB_14002ada0                                   XREF[1]:     14002adf1(j)  
       14002ada0 c5 fe 6f        VMOVDQU    YMM6,ymmword ptr [RBX + RAX*0x1 + 0x1580]
                 b4 03 80 
                 15 00 00
       14002ada9 c5 dd fe db     VPADDD     YMM3,YMM4,YMM3
       14002adad c5 cd f6 f8     VPSADBW    YMM7,YMM6,YMM0
       14002adb1 c5 dd fe e7     VPADDD     YMM4,YMM4,YMM7
       14002adb5 c4 e2 4d        VPMADDUBSW YMM6,YMM6,YMM1
                 04 f1
       14002adba c5 cd f5 f2     VPMADDWD   YMM6,YMM6,YMM2
       14002adbe c5 cd fe ed     VPADDD     YMM5,YMM6,YMM5
       14002adc2 48 85 c0        TEST       RAX,RAX
       14002adc5 0f 84 25        JZ         LAB_14002acf0
                 ff ff ff
       14002adcb c5 fe 6f        VMOVDQU    YMM6,ymmword ptr [RBX + RAX*0x1 + 0x15a0]
                 b4 03 a0 
                 15 00 00
       14002add4 c5 dd fe db     VPADDD     YMM3,YMM4,YMM3
       14002add8 c5 cd f6 f8     VPSADBW    YMM7,YMM6,YMM0
       14002addc c5 dd fe e7     VPADDD     YMM4,YMM4,YMM7
       14002ade0 c4 e2 4d        VPMADDUBSW YMM6,YMM6,YMM1
                 04 f1
       14002ade5 c5 cd f5 f2     VPMADDWD   YMM6,YMM6,YMM2
       14002ade9 c5 cd fe ed     VPADDD     YMM5,YMM6,YMM5
       14002aded 48 83 c0 40     ADD        RAX,0x40
       14002adf1 eb ad           JMP        LAB_14002ada0

Rust loop is cloned once, but you can see that it does almost no memory moves, and so it's 2.5x times faster than my C# implementation.

To optimize this case I think JIT should in optimization phase assess the code to not do any direct manipulation with vector data allocated in stack and, if so, move the vector variables into YMM registers, especially in loops, and move the data from vector registers back into stack if necessary.

[Wraith2]

Can you try this with the current preview and see if the codegen is improved?

[MihaZupan]

This likely isn't helping:
https://github.com/MadProbe/CSharpSimdAdler32/blob/dacc8fad4e7a8a77ab2bac5b34139029465aae59/Program.cs#L43-L48

Try changing it to

Vector256<ulong> vadlerA = Vector256<ulong>.One;
Vector256<uint> vadlerBmult = Vector256<uint>.Zero;
Vector256<ulong> vadlerBA = Vector256<ulong>.Zero;

[benaadams]

Tried both of those

public unsafe uint Vectorized(byte[] data) {
    ArgumentOutOfRangeException.ThrowIfGreaterThan(data.Length, 0x20000, nameof(data)); // cannot guarantee safety (for now)
    ref byte dataRef = ref MemoryMarshal.GetArrayDataReference(data);

    Vector256<sbyte> mults_vector = Vector256.Create(multipliers);
    Vector256<ulong> vadlerA = Vector256<ulong>.One;
    Vector256<uint> vadlerBmult = Vector256<uint>.Zero;
    Vector256<ulong> vadlerBA = Vector256<ulong>.Zero;
    Vector256<byte> vbytezero = Vector256<byte>.Zero;

    Vector256<short> vone_short = Vector256<short>.One;
    for (ref byte end = ref Unsafe.AddByteOffset(ref dataRef, data.Length - data.Length % Vector256<byte>.Count);
            Unsafe.IsAddressLessThan(ref dataRef, ref end);
            dataRef = ref Unsafe.AddByteOffset(ref dataRef, Vector256<byte>.Count))
    {
        var bytes = Vector256.LoadUnsafe(ref dataRef);
        vadlerBA = Avx2.Add(vadlerBA, vadlerA);
        vadlerBmult = Avx2.Add(vadlerBmult, Avx2.MultiplyAddAdjacent(Avx2.MultiplyAddAdjacent(bytes, mults_vector), vone_short).AsUInt32());
        vadlerA = Avx2.Add(vadlerA, Avx2.SumAbsoluteDifferences(bytes, vbytezero).AsUInt64());
    }
    (Vector256<ulong> lower, Vector256<ulong> upper) = Vector256.Widen(vadlerBmult);
    ulong adlerB = Vector512.Sum(Vector512.Create(lower, upper)) + Vector256.Sum(vadlerBA);
    ulong adlerA = Vector256.Sum(vadlerA);

Not sure why it wants ymmword ptr[rsp+100H] to be on stack though 🤔

       jl       G_M000_IG10
       vmovups  ymm0, ymmword ptr[rax+10H]
       vmovups  ymm1, ymmword ptr[reloc @RWD00]
       vmovups  ymmword ptr[rsp+100H], ymm1
       vxorps   ymm1, ymm1, ymm1
       vxorps   ymm2, ymm2, ymm2
       vmovups  ymmword ptr[rsp+E0H], ymm2
       mov      eax, esi
       and      eax, 31
       sub      esi, eax
       movsxd   rax, esi
       add      rax, rdi
       cmp      rdi, rax
       jae      SHORT G_M000_IG06
       align    [1 bytes for IG05]

G_M000_IG05:                ;; offset=0090H
       vmovups  ymm2, ymmword ptr[rdi]
       vmovups  ymm3, ymmword ptr[rsp+E0H]
       vpaddq   ymm3, ymm3, ymmword ptr[rsp+100H]
       vmovups  ymmword ptr[rsp+E0H], ymm3
       vpmaddubsw ymm3, ymm2, ymm0
       vpmaddwd ymm3, ymm3, ymmword ptr[reloc @RWD32]
       vpaddd   ymm1, ymm1, ymm3
       vxorps   ymm3, ymm3, ymm3
       vpsadbw  ymm2, ymm2, ymm3
       vpaddq   ymm2, ymm2, ymmword ptr[rsp+100H]
       vmovups  ymmword ptr[rsp+100H], ymm2
       add      rdi, 32
       cmp      rdi, rax
       jb       SHORT G_M000_IG05

However the Vector512.Sum part is more wild

G_M000_IG06:                ;; offset=00E3H
       vmovaps  ymm0, ymm1
       vpmovzxdq ymm0, ymm0
       vextractf128 xmm1, ymm1, 1
       vpmovzxdq ymm1, ymm1
       vmovups  ymmword ptr[rsp+C0H], ymm0
       vmovups  xmm0, xmmword ptr [rsp+C0H]
       vmovaps  xmmword ptr [rsp+B0H], xmm0
       mov      rax, qword ptr [rsp+B0H]
       add      rax, qword ptr [rsp+B8H]
       mov      rcx, rax
       vmovups  xmm0, xmmword ptr [rsp+D0H]
       vmovaps  xmmword ptr [rsp+A0H], xmm0
       mov      rax, qword ptr [rsp+A0H]
       add      rax, qword ptr [rsp+A8H]
       add      rcx, rax
       vmovups  ymmword ptr[rsp+80H], ymm1
       vmovups  xmm0, xmmword ptr [rsp+80H]
       vmovaps  xmmword ptr [rsp+70H], xmm0
       mov      rax, qword ptr [rsp+70H]
       add      rax, qword ptr [rsp+78H]
       mov      r8, rax
       vmovups  xmm0, xmmword ptr [rsp+90H]
       vmovaps  xmmword ptr [rsp+60H], xmm0
       mov      rax, qword ptr [rsp+60H]
       add      rax, qword ptr [rsp+68H]
       add      rcx, r8
       add      rcx, rax
       vmovups  xmm0, xmmword ptr [rsp+E0H]
       vmovaps  xmmword ptr [rsp+50H], xmm0
       mov      rax, qword ptr [rsp+50H]
       add      rax, qword ptr [rsp+58H]
       mov      r8, rax
       vmovups  xmm0, xmmword ptr [rsp+F0H]
       vmovaps  xmmword ptr [rsp+40H], xmm0
       mov      rax, qword ptr [rsp+40H]
       add      rax, qword ptr [rsp+48H]
       add      rcx, r8
       add      rcx, rax
       vmovups  xmm0, xmmword ptr [rsp+100H]
       vmovaps  xmmword ptr [rsp+30H], xmm0
       mov      rax, qword ptr [rsp+30H]
       add      rax, qword ptr [rsp+38H]
       mov      r8, rax
       vmovups  xmm0, xmmword ptr [rsp+110H]
       vmovaps  xmmword ptr [rsp+20H], xmm0
       mov      rax, qword ptr [rsp+20H]
       add      rax, qword ptr [rsp+28H]
       add      r8, rax
       mov      rdx, 0x4003C038434BF173
       mov      rax, r8
       add      rax, 1
       sbb      rax, 0
       mul      rdx:rax, rdx
       shr      rdx, 14
       imul     rax, rdx, 0xFFF1
       sub      r8, rax
       mov      rdx, 0x4003C038434BF173
       mov      rax, r8
       add      rax, 1
       sbb      rax, 0
       mul      rdx:rax, rdx
       shr      rdx, 14
       imul     rax, rdx, 0xFFF1
       sub      r8, rax
       mov      rdx, 0x4003C038434BF173
       mov      rax, rcx

[MichalPetryka]

However the Vector512.Sum part is more wild

Is this on AVX512 enabled hardware?

[benaadams]

However the Vector512.Sum part is more wild

Is this on AVX512 enabled hardware?

Doesn't need to push everything to stack if it isn't?

[tannergooding]

Doesn't need to push everything to stack if it isn't?

It is not expected that Vector512.Sum have "good" codegen on hardware without the necessary support, that is the purpose of the Vector512.IsHardwareAccelerated check (and correspondingly for Vector64/128/256).

When using Vector512 on unsupported hardware, you are effectively defining a user-defined struct of 2x Vector256 or 4x Vector128.

Such a struct "may" get promoted (on the most recent nightly builds of .NET 8) and "may" get its methods inlined. But otherwise, its like passing around a very large and very expensive 64-byte user-defined struct and it will involve copies and spills due to various APIs being address taken (invoking instance methods) or similar.

In this particular case, you're effectively getting an unrolled loop of 7 separate additions. We could "do better" here, but the general issue is that there is no 64-bit horizontal add on x86/x64 and so it has to pessimize. Shuffling to emulate a horizontal add isn't going to be better. For 256-bit/512-bit, permuting the lanes, adding, and then breaking it down to 2-adds probably would be better, but not by much.

[benaadams]

AVX512 aside 😅

It does prefer the stack to hoisting to ymm outside the loop; even though the ymm is declared outside

[SkipLocalsInit]
public unsafe uint Vectorized(byte[] data) {
    ArgumentOutOfRangeException.ThrowIfGreaterThan(data.Length, 0x20000, nameof(data)); // cannot guarantee safety (for now)
    ref byte dataRef = ref MemoryMarshal.GetArrayDataReference(data);

    Vector256<sbyte> mults_vector = Vector256.Create(multipliers);
    Vector256<ulong> vadlerA = Vector256<ulong>.One;
    Vector256<uint> vadlerBmult = Vector256<uint>.Zero;
    Vector256<ulong> vadlerBA = Vector256<ulong>.Zero;

    Vector256<byte> vbytezero = Vector256<byte>.Zero;
    Vector256<short> vone_short = Vector256<short>.One;

    for (ref byte end = ref Unsafe.AddByteOffset(ref dataRef, data.Length - data.Length % Vector256<byte>.Count);
            Unsafe.IsAddressLessThan(ref dataRef, ref end);
            dataRef = ref Unsafe.AddByteOffset(ref dataRef, Vector256<byte>.Count))
    {
        var bytes = Vector256.LoadUnsafe(ref dataRef);
        vadlerBA = Avx2.Add(vadlerBA, vadlerA);
        vadlerBmult = Avx2.Add(vadlerBmult, Avx2.MultiplyAddAdjacent(Avx2.MultiplyAddAdjacent(bytes, mults_vector), vone_short).AsUInt32());
        vadlerA = Avx2.Add(vadlerA, Avx2.SumAbsoluteDifferences(bytes, vbytezero).AsUInt64());
    }
    //(Vector256<ulong> lower, Vector256<ulong> upper) = Vector256.Widen(vadlerBmult);
    //ulong adlerB = Vector512.Sum(Vector512.Create(lower, upper)) + Vector256.Sum(vadlerBA);
    ulong adlerB = Vector256.Sum(vadlerBmult) + Vector256.Sum(vadlerBA);
    ulong adlerA = Vector256.Sum(vadlerA);
    //Span<byte> remaining = new SpanBlockIterator<byte>(data, Vector256<byte>.Count).Remaining;
    adlerA %= 0xFFF1UL;
    adlerB %= 0xFFF1UL;

    //for (int i = 0, length = remaining.Length; i < length; i++)
    //{
    //    adlerA += remaining[i];
    //    adlerB += adlerA;
    //}

    return (uint)(adlerB % 0xFFF1 << 16 | adlerA % 0xFFF1);
}
private static readonly sbyte[] multipliers = new sbyte[(256 / (sizeof(sbyte) * 8))] { 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 };

G_M000_IG01:
       push     rdi
       push     rsi
       sub      rsp, 168
       vzeroupper 

G_M000_IG02:
       mov      esi, dword ptr [rdx+08H]
       mov      edi, esi
       cmp      edi, 0x20000
       jl       SHORT G_M000_IG04

G_M000_IG03:
       cmp      edi, 0x20000
       jg       G_M000_IG08

G_M000_IG04:
       lea      rdi, bword ptr [rdx+10H]
       mov      rcx, 0x7FF9D74D0828
       mov      edx, 6
       call     CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE
       mov      rax, 0x23665401D58
       mov      rax, gword ptr [rax]
       mov      edx, dword ptr [rax+08H]
       cmp      edx, 32
       jl       G_M000_IG09
       vmovups  ymm0, ymmword ptr[rax+10H]
       vmovups  ymm1, ymmword ptr[reloc @RWD00]
       vmovups  ymmword ptr[rsp+80H], ymm1
       vxorps   ymm1, ymm1, ymm1
       vxorps   ymm2, ymm2, ymm2
       vmovups  ymmword ptr[rsp+60H], ymm2
       mov      eax, esi
       and      eax, 31
       sub      esi, eax
       movsxd   rax, esi
       add      rax, rdi
       cmp      rdi, rax
       jae      SHORT G_M000_IG06
       align    [0 bytes for IG05]

G_M000_IG05:
       vmovups  ymm2, ymmword ptr[rdi]                  ; valid load
       vmovups  ymm3, ymmword ptr[rsp+60H]              ;  should be in reg?
       vpaddq   ymm3, ymm3, ymmword ptr[rsp+80H]        ;  should be in reg?
       vmovups  ymmword ptr[rsp+60H], ymm3              ;  should be in reg?
       vpmaddubsw ymm3, ymm2, ymm0
       vpmaddwd ymm3, ymm3, ymmword ptr[reloc @RWD32]   ;  should be in reg?
       vpaddd   ymm1, ymm1, ymm3
       vxorps   ymm3, ymm3, ymm3
       vpsadbw  ymm2, ymm2, ymm3
       vpaddq   ymm2, ymm2, ymmword ptr[rsp+80H]        ;  should be in reg?
       vmovups  ymmword ptr[rsp+80H], ymm2              ;  should be in reg?
       add      rdi, 32
       cmp      rdi, rax
       jb       SHORT G_M000_IG05

Isn't particularly the number of registers as if vbytezero and vone_short are dropped and their direct values of .One and .Zero used inside the loop; then it will happily use an extra ymm reg 🤔

    Vector256<sbyte> mults_vector = Vector256.Create(multipliers);
    Vector256<ulong> vadlerA = Vector256<ulong>.One;
    Vector256<uint> vadlerBmult = Vector256<uint>.Zero;
    Vector256<ulong> vadlerBA = Vector256<ulong>.Zero;

    for (ref byte end = ref Unsafe.AddByteOffset(ref dataRef, data.Length - data.Length % Vector256<byte>.Count);
            Unsafe.IsAddressLessThan(ref dataRef, ref end);
            dataRef = ref Unsafe.AddByteOffset(ref dataRef, Vector256<byte>.Count))
    {
        var bytes = Vector256.LoadUnsafe(ref dataRef);
        vadlerBA = Avx2.Add(vadlerBA, vadlerA);
        vadlerBmult = Avx2.Add(vadlerBmult, Avx2.MultiplyAddAdjacent(Avx2.MultiplyAddAdjacent(bytes, mults_vector), Vector256<short>.One).AsUInt32());
        vadlerA = Avx2.Add(vadlerA, Avx2.SumAbsoluteDifferences(bytes, Vector256<byte>.Zero).AsUInt64());
    }

G_M000_IG05:
       vmovups  ymm3, ymmword ptr[rdi]
       vmovups  ymm4, ymmword ptr[rsp+60H]
       vpaddq   ymm4, ymm4, ymmword ptr[rsp+80H]
       vmovups  ymmword ptr[rsp+60H], ymm4
       vpmaddubsw ymm4, ymm3, ymm0
       vpmaddwd ymm4, ymm4, ymm2
       vpaddd   ymm1, ymm1, ymm4
       vxorps   ymm4, ymm4, ymm4
       vpsadbw  ymm3, ymm3, ymm4
       vpaddq   ymm3, ymm3, ymmword ptr[rsp+80H]
       vmovups  ymmword ptr[rsp+80H], ymm3
       add      rdi, 32
       cmp      rdi, rcx
       jb       SHORT G_M000_IG05

[MadProbe]

Isn't particularly the number of registers as if vbytezero and vone_short are dropped and their direct values of .One and .Zero used inside the loop; then it will happily use an extra ymm reg 🤔

To be honest I expected that the exact opposite happens.

Can you try this with the current preview and see if the codegen is improved?

I have already tried this on latest preview version 8.0.0-preview3 and on preview2, the same thing happens. If you want me to test it on nightly version of runtime, I don't want to do it as it would be too tedious to make for little outcome.

[MadProbe]

However the Vector512.Sum part is more wild

Is this on AVX512 enabled hardware?

My processor doesn't have AVX-512 hardware instructions, so it's expected

[MadProbe]

Isn't particularly the number of registers as if vbytezero and vone_short are dropped and their direct values of .One and .Zero used inside the loop; then it will happily use an extra ymm reg 🤔

To be honest I expected that the exact opposite happens.

To elaborate, I expected for zero to come out of the loop so vxorps ymm4, ymm4, ymm4 doesn't happen and to win some performance

AVX512 aside 😅

It does prefer the stack to hoisting to ymm outside the loop; even though the ymm is declared outside

Also it's important to widen vadletBmult's values should all be close to maximum of uint.MaxValue and I expect it to overflow when values are summed if not widened.

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I am creating an implementation of adler32 checksum using C# and I am getting significant performance regression in comparison with implementation written in rust - simd-adler32 by nearly 2.5 times.
benchmark repository with source code

Configuration

See benchmark results

Regression?

Reproducible in .NET 7.0.

Data

BenchmarkDotNet=v0.13.5, OS=Windows 10 (10.0.19043.2251/21H1/May2021Update)
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET SDK=8.0.100-preview.3.23178.7
  [Host]     : .NET 8.0.0 (8.0.23.17408), X64 RyuJIT AVX2
  DefaultJob : .NET 8.0.0 (8.0.23.17408), X64 RyuJIT AVX2


|     Method |         data |       Mean |     Error |    StdDev | Ratio | Code Size |
|----------- |------------- |-----------:|----------:|----------:|------:|----------:|
| Vectorized | Byte[102400] |   8.366 us | 0.0691 us | 0.0646 us |  0.02 |     902 B |
|      Naive | Byte[102400] | 412.368 us | 2.9653 us | 2.7738 us |  1.00 |     215 B |

adler32 simd implementation written in rust benchmark for avx2 using criterion.rs:

avx2/random-100k        time:   [3.5483 us 3.5684 us 3.5922 us]
                        thrpt:  [25.926 GiB/s 26.099 GiB/s 26.247 GiB/s]
--- some stuff is skipped
avx2/random-100k        time:   [3.5438 us 3.5655 us 3.5892 us]
                        thrpt:  [25.948 GiB/s 26.121 GiB/s 26.280 GiB/s]
                 change:
                        time:   [-1.5116% +0.2112% +2.0511%] (p = 0.82 > 0.05)
                        thrpt:  [-2.0099% -0.2107% +1.5348%]
                        No change in performance detected.

Analysis

Comparing disassemblied code for rust and my c# implementation, the main problem lies in computation loop: there are too much memory <-> vector moves there and it can be much more efficient if more YMM registers were used:

My C# code disassembly:

--- omitted for brevity
M00_L01:
       vmovups   ymm1,[rcx]
       vmovups   ymm2,[r10]
       vpaddq    ymm2,ymm2,[r8]
       vmovups   [r10],ymm2
       vpmaddubsw ymm2,ymm1,ymm0
       vpmaddwd  ymm2,ymm2,[7FFBA0BC7820]
       vpaddd    ymm2,ymm2,[r9]
       vmovups   [r9],ymm2
       vxorps    ymm2,ymm2,ymm2
       vpsadbw   ymm1,ymm1,ymm2
       vpaddq    ymm1,ymm1,[r8]
       vmovups   [r8],ymm1
       add       rcx,20
       cmp       rcx,r11
       jb        short M00_L01
--- omitted for brevity

And rust code loop:
source: https://github.com/mcountryman/simd-adler32/blob/main/src/imp/avx2.rs#L123-L132

--- Decompiled using Ghidra
                             LAB_14002ada0                                   XREF[1]:     14002adf1(j)  
       14002ada0 c5 fe 6f        VMOVDQU    YMM6,ymmword ptr [RBX + RAX*0x1 + 0x1580]
                 b4 03 80 
                 15 00 00
       14002ada9 c5 dd fe db     VPADDD     YMM3,YMM4,YMM3
       14002adad c5 cd f6 f8     VPSADBW    YMM7,YMM6,YMM0
       14002adb1 c5 dd fe e7     VPADDD     YMM4,YMM4,YMM7
       14002adb5 c4 e2 4d        VPMADDUBSW YMM6,YMM6,YMM1
                 04 f1
       14002adba c5 cd f5 f2     VPMADDWD   YMM6,YMM6,YMM2
       14002adbe c5 cd fe ed     VPADDD     YMM5,YMM6,YMM5
       14002adc2 48 85 c0        TEST       RAX,RAX
       14002adc5 0f 84 25        JZ         LAB_14002acf0
                 ff ff ff
       14002adcb c5 fe 6f        VMOVDQU    YMM6,ymmword ptr [RBX + RAX*0x1 + 0x15a0]
                 b4 03 a0 
                 15 00 00
       14002add4 c5 dd fe db     VPADDD     YMM3,YMM4,YMM3
       14002add8 c5 cd f6 f8     VPSADBW    YMM7,YMM6,YMM0
       14002addc c5 dd fe e7     VPADDD     YMM4,YMM4,YMM7
       14002ade0 c4 e2 4d        VPMADDUBSW YMM6,YMM6,YMM1
                 04 f1
       14002ade5 c5 cd f5 f2     VPMADDWD   YMM6,YMM6,YMM2
       14002ade9 c5 cd fe ed     VPADDD     YMM5,YMM6,YMM5
       14002aded 48 83 c0 40     ADD        RAX,0x40
       14002adf1 eb ad           JMP        LAB_14002ada0

Rust loop is cloned once, but you can see that it does almost no memory moves, and so it's 2.5x times faster than my C# implementation.

To optimize this case I think JIT should in optimization phase assess the code to not do any direct manipulation with vector data allocated in stack and, if so, move the vector variables into YMM registers, especially in loops, and move the data from vector registers back into stack if necessary.

Author:	MadProbe
Assignees:	-
Labels:	tenet-performance, area-CodeGen-coreclr, untriaged, needs-area-label
Milestone:	-