c# - 结构元组的性能

Question

以下 F# 程序定义了一个函数，该函数返回表示为结构元组的两对整数中较小的一个，运行时间为 1.4 秒:

let [<EntryPoint>] main _ =
  let min a b : int = if a < b then a else b
  let min (struct(a1, b1)) (struct(a2, b2)) = struct(min a1 a2, min b1 b2)
  let mutable x = struct(0, 0)
  for i in 1..100000000 do
    x <- min x (struct(i, i))
  0

如果我将 CIL 反编译为 C#，我会得到以下代码:

    public static int MinInt(int a, int b)
    {
        if (a < b)
        {
            return a;
        }
        return b;
    }

    public static System.ValueTuple<int, int> MinPair(System.ValueTuple<int, int> _arg2, System.ValueTuple<int, int> _arg1)
    {
        int b = _arg2.Item2;
        int a = _arg2.Item1;
        int b2 = _arg1.Item2;
        int a2 = _arg1.Item1;
        return new System.ValueTuple<int, int>(MinInt(a, a2), MinInt(b, b2));
    }

    public static void Main(string[] args)
    {
        System.ValueTuple<int, int> x = new System.ValueTuple<int, int>(0, 0);
        for (int i = 1; i <= 100000000; i++)
        {
            x = MinPair(x, new System.ValueTuple<int, int>(i, i));
        }
    }

使用 C# 编译器重新编译只需 0.3 秒，比原始 F# 快 4 倍多。

我不明白为什么一个程序比另一个程序快得多。我什至将两个版本都反编译为 CIL，但看不出任何明显的原因。从 F# 调用 C# Min 函数会产生相同(较差)的性能。调用者内部循环的 CIL 完全相同。

谁能解释这种显着的性能差异？

Answer 1

您是否在同一架构中运行这两个示例。对于 F# 和 C# 代码，我在 x64 上得到了大约 1.4 秒，对于 F#，在 x86 上得到了大约 0.6 秒，对于 C#，在 x86 上得到了大约 0.3 秒。

正如您在反编译程序集时所说，代码看起来非常相似，但在检查 IL 代码时会出现一些差异:

F# - let min (struct(a1, b1)) (struct(a2, b2)) ...

.maxstack 5
.locals init (
  [0] int32 b1,
  [1] int32 a1,
  [2] int32 b2,
  [3] int32 a2
)

IL_0000: ldarga.s _arg2
IL_0002: ldfld !1 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item2
IL_0007: stloc.0
IL_0008: ldarga.s _arg2
IL_000a: ldfld !0 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item1
IL_000f: stloc.1
IL_0010: ldarga.s _arg1
IL_0012: ldfld !1 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item2
IL_0017: stloc.2
IL_0018: ldarga.s _arg1
IL_001a: ldfld !0 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item1
IL_001f: stloc.3
IL_0020: nop
IL_0021: ldloc.1
IL_0022: ldloc.3
IL_0023: call int32 Program::min@8(int32, int32)
IL_0028: ldloc.0
IL_0029: ldloc.2
IL_002a: call int32 Program::min@8(int32, int32)
IL_002f: newobj instance void valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::.ctor(!0, !1)
IL_0034: ret

C# - MinPair

.maxstack 3
.locals init (
  [0] int32 b,
  [1] int32 b2,
  [2] int32 a2
)

IL_0000: ldarg.0
IL_0001: ldfld !1 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item2
IL_0006: stloc.0
IL_0007: ldarg.0
IL_0008: ldfld !0 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item1
IL_000d: ldarg.1
IL_000e: ldfld !1 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item2
IL_0013: stloc.1
IL_0014: ldarg.1
IL_0015: ldfld !0 valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::Item1
IL_001a: stloc.2
IL_001b: ldloc.2
IL_001c: call int32 PerfItCs.Program::MinInt(int32, int32)
IL_0021: ldloc.0
IL_0022: ldloc.1
IL_0023: call int32 PerfItCs.Program::MinInt(int32, int32)
IL_0028: newobj instance void valuetype [System.ValueTuple]System.ValueTuple`2<int32, int32>::.ctor(!0, !1)
IL_002d: ret

这里的区别在于，C# 编译器通过将中间结果压入堆栈来避免引入一些局部变量。由于无论如何都会在堆栈上分配局部变量，因此很难理解为什么这会导致更高效的代码。

其他功能非常相似。

反汇编 x86 会产生这样的结果:

F# - 循环

; F#
; struct (i, i) 
01690a7e 8bce            mov     ecx,esi
01690a80 8bd6            mov     edx,esi
; Loads x (pair) onto stack
01690a82 8d45f0          lea     eax,[ebp-10h]
01690a85 83ec08          sub     esp,8
01690a88 f30f7e00        movq    xmm0,mmword ptr [eax]
01690a8c 660fd60424      movq    mmword ptr [esp],xmm0
; Push new tuple on stack
01690a91 52              push    edx
01690a92 51              push    ecx
; Loads pointer to x into ecx (result will be written here)
01690a93 8d4df0          lea     ecx,[ebp-10h]
; Call min
01690a96 ff15744dfe00    call    dword ptr ds:[0FE4D74h]
; Increase i
01690a9c 46              inc     esi
01690a9d 81fe01e1f505    cmp     esi,offset FSharp_Core_ni+0x6be101 (05f5e101)
; Reached the end?
01690aa3 7cd9            jl      01690a7e

C# - 循环

; C#
; Loads x (pair) into ecx, eax
02c2057b 8d55ec          lea     edx,[ebp-14h]
02c2057e 8b0a            mov     ecx,dword ptr [edx]
02c20580 8b4204          mov     eax,dword ptr [edx+4]
; new System.ValueTuple<int, int>(i, i) 
02c20583 8bfe            mov     edi,esi
02c20585 8bd6            mov     edx,esi
; Push x on stack
02c20587 50              push    eax
02c20588 51              push    ecx
; Push new tuple on stack
02c20589 52              push    edx
02c2058a 57              push    edi
; Loads pointer to x into ecx (result will be written here)
02c2058b 8d4dec          lea     ecx,[ebp-14h]
; Call MinPair
02c2058e ff15104d2401    call    dword ptr ds:[1244D10h]
; Increase i
02c20594 46              inc     esi
; Reached the end?
02c20595 81fe00e1f505    cmp     esi,5F5E100h
02c2059b 7ede            jle     02c2057b

很难理解为什么 F# 代码在这里的性能要差得多。除了 x 是如何加载到堆栈上的异常(exception)情况，代码看起来大致相同。直到有人想出一个很好的解释为什么我要推测它是因为 movq 比 push 有更糟糕的延迟并且因为所有指令都操纵堆栈，CPU 不能重新排序指令以减少 movq 的延迟。

为什么抖音选择movq作为F#代码而不是C#代码我目前还不知道。

对于 x64，性能似乎变差了，因为方法前奏的开销更大，而且由于别名而造成的停顿更多。这主要是我的猜测，但很难从汇编代码中看出除了停止之外还有什么会使 x64 的性能降低 4 倍。

通过将 min 标记为内联，x64 和 x86 都在大约 0.15 秒内运行。毫不奇怪，因为这消除了方法前奏和大量读取和写入堆栈的所有开销。

将 F# 方法标记为积极内联(使用 [MethodImpl (MethodImplOptions.AggressiveInlining)])不起作用，因为 F# 编译器删除了所有此类属性，这意味着抖动永远不会看到它，而是标记 C# 方法积极内联使 C# 代码在 ~0.15 秒内运行。

所以最终 x86 抖动出于某种原因选择了不同的 jit 代码，即使 IL 代码看起来非常相似。方法的属性可能会影响抖动，因为它们有些不同。

x64 抖动可能可以更好地以更有效的方式将参数插入堆栈。我猜想使用 push 因为 x86 抖动比 mov 更可取，因为 push 的语义更受限制，但这只是我的猜测。

在这种情况下，当方法成本较低时，将它们标记为内联可能会很好。

老实说，我不确定这对 OP 有帮助，但希望它有点有趣。

附言。我在 i5 3570K 上的 .NET 4.6.2 上运行代码