Add Support for Vector512 in BinaryPrimitives.ReverseEndianness (#108204)

[masterworgen]

Fixes #108204. I add support Vector512 in BinaryPrimitives.ReverseEndianness.

[masterworgen]

@dotnet-policy-service agree

@dotnet-policy-service agree

[EgorBo]

@EgorBot -intel -perf

using System.Buffers.Binary;
using BenchmarkDotNet.Attributes;

public class Bench
{
    int[] arr1 = new int[1024];
    int[] arr2 = new int[1024];

    [Benchmark]
    public void Reverse() => 
        BinaryPrimitives.ReverseEndianness(arr1, arr2);
}

[EgorBo]

@EgorBot -intel -aws_amd -perf

using System.Buffers.Binary;
using System.Runtime.InteropServices;
using BenchmarkDotNet.Attributes;

public unsafe class Bench
{
    static void* src;
    static void* dst;

    [GlobalSetup]
    public void Setup()
    {
        src = NativeMemory.AlignedAlloc(1024 * 4, 64);
        dst = NativeMemory.AlignedAlloc(1024 * 4, 64);
    }

    [GlobalCleanup]
    public void Cleanup()
    {
        NativeMemory.AlignedFree(src);
        NativeMemory.AlignedFree(dst);
    }

    [Benchmark]
    public void Reverse() => 
        BinaryPrimitives.ReverseEndianness(
            new ReadOnlySpan<int>(src, 1024), 
            new Span<int>(dst, 1024));
}

[EgorBo]

So, as the benchmarks state, the Avx512 acceleration for such a trivial routine (load->store) only makes sense when data is aligned.

Data is 64 bytes aligned (~2x improvement as expected):

Data is 8 bytes aligned (regressed by ~30%):

so this change has to make sure data is aligned before doing the main loop.

[tannergooding]

This is pending the cleanup suggested by Egor above to ensure we don't regress performance unnecessarily.

More ideally this would be rewritten to use the internal ISimdVector and potentially have a setup closer to what TensorPrimitives uses internally, which handles opportunistic alignment, large and small inputs, etc. However, that may be work that is better done more holistically and not incrementally, picking up and sharing the existing logic that TensorPrimitives has done; so may be better driven explicitly by the .NET team when we're ready to complete such work.

[masterworgen]

This is pending the cleanup suggested by Egor above to ensure we don't regress performance unnecessarily.

More ideally this would be rewritten to use the internal ISimdVector and potentially have a setup closer to what TensorPrimitives uses internally, which handles opportunistic alignment, large and small inputs, etc. However, that may be work that is better done more holistically and not incrementally, picking up and sharing the existing logic that TensorPrimitives has done; so may be better driven explicitly by the .NET team when we're ready to complete such work.

Should I close this PR then?