為什么通過Pointer轉換結構很慢，而Unsafe.As很快？

Question

背景

我想制作一些整數大小的struct （即32位和64位），它們可以輕松轉換為相同大小的原始非托管類型（特別是32位大小的結構的Int32和UInt32 ）。

然后，結構將公開用於位操作/索引的附加功能，這些功能不能直接在整數類型上使用。 基本上，作為一種語法糖，提高可讀性和易用性。

然而，重要的部分是性能，因為這個額外的抽象應該基本上是0成本（在一天結束時，CPU應該“看到”相同的位，就好像處理原始的整數一樣）。

樣本結構

下面是我提出的非常基本的struct 。 它沒有所有功能，但足以說明我的問題：

[StructLayout(LayoutKind.Explicit, Pack = 1, Size = 4)]
public struct Mask32 {
  [FieldOffset(3)]
  public byte Byte1;
  [FieldOffset(2)]
  public ushort UShort1;
  [FieldOffset(2)]
  public byte Byte2;
  [FieldOffset(1)]
  public byte Byte3;
  [FieldOffset(0)]
  public ushort UShort2;
  [FieldOffset(0)]
  public byte Byte4;

  [DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
  public static unsafe implicit operator Mask32(int i) => *(Mask32*)&i;
  [DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
  public static unsafe implicit operator Mask32(uint i) => *(Mask32*)&i;
}

考試

我想測試這個結構的性能。 特別是我想看看它是否可以讓我像使用常規的位運算一樣快速地獲得單個字節 ： (i >> 8) & 0xFF （例如獲取第3個字節）。

下面你會看到我提出的基准：

public unsafe class MyBenchmark {

  const int count = 50000;

  [Benchmark(Baseline = true)]
  public static void Direct() {
    var j = 0;
    for (int i = 0; i < count; i++) {
      //var b1 = i.Byte1();
      //var b2 = i.Byte2();
      var b3 = i.Byte3();
      //var b4 = i.Byte4();
      j += b3;
    }
  }


  [Benchmark]
  public static void ViaStructPointer() {
    var j = 0;
    int i = 0;
    var s = (Mask32*)&i;
    for (; i < count; i++) {
      //var b1 = s->Byte1;
      //var b2 = s->Byte2;
      var b3 = s->Byte3;
      //var b4 = s->Byte4;
      j += b3;
    }
  }

  [Benchmark]
  public static void ViaStructPointer2() {
    var j = 0;
    int i = 0;
    for (; i < count; i++) {
      var s = *(Mask32*)&i;
      //var b1 = s.Byte1;
      //var b2 = s.Byte2;
      var b3 = s.Byte3;
      //var b4 = s.Byte4;
      j += b3;
    }
  }

  [Benchmark]
  public static void ViaStructCast() {
    var j = 0;
    for (int i = 0; i < count; i++) {
      Mask32 m = i;
      //var b1 = m.Byte1;
      //var b2 = m.Byte2;
      var b3 = m.Byte3;
      //var b4 = m.Byte4;
      j += b3;
    }
  }

  [Benchmark]
  public static void ViaUnsafeAs() {
    var j = 0;
    for (int i = 0; i < count; i++) {
      var m = Unsafe.As<int, Mask32>(ref i);
      //var b1 = m.Byte1;
      //var b2 = m.Byte2;
      var b3 = m.Byte3;
      //var b4 = m.Byte4;
      j += b3;
    }
  }

}

Byte1() ， Byte2() ， Byte3()和Byte4()只是通過執行按位運算和轉換來獲取內聯並簡單地獲取第n個字節的擴展方法：

[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte1(this int it) => (byte)(it >> 24);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte2(this int it) => (byte)((it >> 16) & 0xFF);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte3(this int it) => (byte)((it >> 8) & 0xFF);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte4(this int it) => (byte)it;

編輯：修復了確保變量實際使用的代碼。 還注釋了4個變量中的3個來真正測試結構轉換/成員訪問而不是實際使用變量。

結果

我在Release版本中運行了這些，並在x64上進行了優化。

Intel Core i7-3770K CPU 3.50GHz (Ivy Bridge), 1 CPU, 8 logical cores and 4 physical cores
Frequency=3410223 Hz, Resolution=293.2360 ns, Timer=TSC
  [Host]     : .NET Framework 4.6.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.6.1086.0
  DefaultJob : .NET Framework 4.6.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.6.1086.0


            Method |      Mean |     Error |    StdDev | Scaled | ScaledSD |
------------------ |----------:|----------:|----------:|-------:|---------:|
            Direct |  14.47 us | 0.3314 us | 0.2938 us |   1.00 |     0.00 |
  ViaStructPointer | 111.32 us | 0.6481 us | 0.6062 us |   7.70 |     0.15 |
 ViaStructPointer2 | 102.31 us | 0.7632 us | 0.7139 us |   7.07 |     0.14 |
     ViaStructCast |  29.00 us | 0.3159 us | 0.2800 us |   2.01 |     0.04 |
       ViaUnsafeAs |  14.32 us | 0.0955 us | 0.0894 us |   0.99 |     0.02 |

編輯：修復代碼后的新結果：

            Method |      Mean |     Error |    StdDev | Scaled | ScaledSD |
------------------ |----------:|----------:|----------:|-------:|---------:|
            Direct |  57.51 us | 1.1070 us | 1.0355 us |   1.00 |     0.00 |
  ViaStructPointer | 203.20 us | 3.9830 us | 3.5308 us |   3.53 |     0.08 |
 ViaStructPointer2 | 198.08 us | 1.8411 us | 1.6321 us |   3.45 |     0.06 |
     ViaStructCast |  79.68 us | 1.5478 us | 1.7824 us |   1.39 |     0.04 |
       ViaUnsafeAs |  57.01 us | 0.8266 us | 0.6902 us |   0.99 |     0.02 |

問題

基准測試結果讓我感到驚訝，這就是為什么我有幾個問題：

編輯：更改代碼后仍然存在較少的問題，以便實際使用變量。

1. 為什么指針的東西 所以 慢？
2. 為什么演員陣容的時間是基准案例的兩倍？ 內聯/顯式運算符不是內聯的嗎？
3. 為什么新的System.Runtime.CompilerServices.Unsafe包（v.4.5.0）如此之快？ 我認為它至少會涉及一個方法調用...
4. 更一般地說，我如何制作一個零成本的結構，它只是作為某個內存的“窗口”或像UInt64這樣的大型原始類型，這樣我就可以更有效地操作/讀取該內存？ 這里的最佳做法是什么？

Answer 1

對此的答案似乎是，當您使用Unsafe.As()時，JIT編譯器可以更好地進行某些優化。

Unsafe.As()的實現非常簡單：

public static ref TTo As<TFrom, TTo>(ref TFrom source)
{
    return ref source;
}

而已！

這是我寫的一個測試程序，用於比較鑄造：

using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

namespace Demo
{
    [StructLayout(LayoutKind.Explicit, Pack = 1, Size = 4)]
    public struct Mask32
    {
        [FieldOffset(3)]
        public byte Byte1;
        [FieldOffset(2)]
        public ushort UShort1;
        [FieldOffset(2)]
        public byte Byte2;
        [FieldOffset(1)]
        public byte Byte3;
        [FieldOffset(0)]
        public ushort UShort2;
        [FieldOffset(0)]
        public byte Byte4;
    }

    public static unsafe class Program
    {
        static int count = 50000000;

        public static int ViaStructPointer()
        {
            int total = 0;

            for (int i = 0; i < count; i++)
            {
                var s = (Mask32*)&i;
                total += s->Byte1;
            }

            return total;
        }

        public static int ViaUnsafeAs()
        {
            int total = 0;

            for (int i = 0; i < count; i++)
            {
                var m = Unsafe.As<int, Mask32>(ref i);
                total += m.Byte1;
            }

            return total;
        }

        public static void Main(string[] args)
        {
            var sw = new Stopwatch();

            sw.Restart();
            ViaStructPointer();
            Console.WriteLine("ViaStructPointer took " + sw.Elapsed);

            sw.Restart();
            ViaUnsafeAs();
            Console.WriteLine("ViaUnsafeAs took " + sw.Elapsed);
        }
    }
}

我在PC上獲得的結果（x64版本構建）如下：

ViaStructPointer took 00:00:00.1314279
ViaUnsafeAs took 00:00:00.0249446

如您所見， ViaUnsafeAs確實快得多。

那么讓我們看一下編譯器生成的內容：

public static unsafe int ViaStructPointer()
{
    int total = 0;
    for (int i = 0; i < Program.count; i++)
    {
        total += (*(Mask32*)(&i)).Byte1;
    }
    return total;
}

public static int ViaUnsafeAs()
{
    int total = 0;
    for (int i = 0; i < Program.count; i++)
    {
        total += (Unsafe.As<int, Mask32>(ref i)).Byte1;
    }
    return total;
}   

好的，那里沒有什么明顯的。 但是IL怎么樣？

.method public hidebysig static int32 ViaStructPointer () cil managed 
{
    .locals init (
        [0] int32 total,
        [1] int32 i,
        [2] valuetype Demo.Mask32* s
    )

    IL_0000: ldc.i4.0
    IL_0001: stloc.0
    IL_0002: ldc.i4.0
    IL_0003: stloc.1
    IL_0004: br.s IL_0017
    .loop
    {
        IL_0006: ldloca.s i
        IL_0008: conv.u
        IL_0009: stloc.2
        IL_000a: ldloc.0
        IL_000b: ldloc.2
        IL_000c: ldfld uint8 Demo.Mask32::Byte1
        IL_0011: add
        IL_0012: stloc.0
        IL_0013: ldloc.1
        IL_0014: ldc.i4.1
        IL_0015: add
        IL_0016: stloc.1

        IL_0017: ldloc.1
        IL_0018: ldsfld int32 Demo.Program::count
        IL_001d: blt.s IL_0006
    }

    IL_001f: ldloc.0
    IL_0020: ret
}

.method public hidebysig static int32 ViaUnsafeAs () cil managed 
{
    .locals init (
        [0] int32 total,
        [1] int32 i,
        [2] valuetype Demo.Mask32 m
    )

    IL_0000: ldc.i4.0
    IL_0001: stloc.0
    IL_0002: ldc.i4.0
    IL_0003: stloc.1
    IL_0004: br.s IL_0020
    .loop
    {
        IL_0006: ldloca.s i
        IL_0008: call valuetype Demo.Mask32& [System.Runtime.CompilerServices.Unsafe]System.Runtime.CompilerServices.Unsafe::As<int32, valuetype Demo.Mask32>(!!0&)
        IL_000d: ldobj Demo.Mask32
        IL_0012: stloc.2
        IL_0013: ldloc.0
        IL_0014: ldloc.2
        IL_0015: ldfld uint8 Demo.Mask32::Byte1
        IL_001a: add
        IL_001b: stloc.0
        IL_001c: ldloc.1
        IL_001d: ldc.i4.1
        IL_001e: add
        IL_001f: stloc.1

        IL_0020: ldloc.1
        IL_0021: ldsfld int32 Demo.Program::count
        IL_0026: blt.s IL_0006
    }

    IL_0028: ldloc.0
    IL_0029: ret
}

啊哈！ 這里唯一的區別是：

ViaStructPointer: conv.u
ViaUnsafeAs:      call valuetype Demo.Mask32& [System.Runtime.CompilerServices.Unsafe]System.Runtime.CompilerServices.Unsafe::As<int32, valuetype Demo.Mask32>(!!0&)
                  ldobj Demo.Mask32

從表面conv.u ，你會期望conv.u比用於Unsafe.As的兩條指令更快。 但是，似乎JIT編譯器能夠比單個conv.u更好地優化這兩個指令。

有理由問為什么會這樣 - 很遺憾我還沒有答案！ 我幾乎可以肯定，JITTER正在內聯對Unsafe::As<>()的調用，它正在被JIT進一步優化。

這里有關於Unsafe類優化的一些信息。

請注意，為Unsafe.As<>生成的IL只是這樣：

.method public hidebysig static !!TTo& As<TFrom, TTo> (
        !!TFrom& source
    ) cil managed aggressiveinlining 
{
    .custom instance void System.Runtime.Versioning.NonVersionableAttribute::.ctor() = (
        01 00 00 00
    )
    IL_0000: ldarg.0
    IL_0001: ret
}

現在我認為為什么JITTER能夠如此好地優化它變得更加清晰。

Answer 2

當你獲取本地的地址時，jit通常必須將該本地保留在堆棧中。 就是這種情況。 在ViaPointer版本中， i保留在堆棧中。 在ViaUnsafe ， i被復制到temp，並且temp被保留在堆棧中。 前者較慢，因為i也習慣於控制循環的迭代。

您可以使用以下代碼非常接近ViaUnsafe perf，您可以在其中明確復制：

    public static int ViaStructPointer2()
    {
        int total = 0;

        for (int i = 0; i < count; i++)
        {
            int j = i;
            var s = (Mask32*)&j;
            total += s->Byte1;
        }

        return total;
    }

ViaStructPointer  took 00:00:00.1147793
ViaUnsafeAs       took 00:00:00.0282828
ViaStructPointer2 took 00:00:00.0257589