尝试捕获加快我的代码?

我编写了一些代码来测试 try-catch 的影响,但是看到了一些令人惊讶的结果。

static void Main(string[] args)
{
    Thread.CurrentThread.Priority = ThreadPriority.Highest;
    Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;

    long start = 0, stop = 0, elapsed = 0;
    double avg = 0.0;

    long temp = Fibo(1);

    for (int i = 1; i < 100000000; i++)
    {
        start = Stopwatch.GetTimestamp();
        temp = Fibo(100);
        stop = Stopwatch.GetTimestamp();

        elapsed = stop - start;
        avg = avg + ((double)elapsed - avg) / i;
    }

    Console.WriteLine("Elapsed: " + avg);
    Console.ReadKey();
}

static long Fibo(int n)
{
    long n1 = 0, n2 = 1, fibo = 0;
    n++;

    for (int i = 1; i < n; i++)
    {
        n1 = n2;
        n2 = fibo;
        fibo = n1 + n2;
    }

    return fibo;
}

在我的计算机上,这将始终输出约 0.96 的值。

当我用一个 try-catch 块在 Fibo()中包装 for 循环时,如下所示:

static long Fibo(int n)
{
    long n1 = 0, n2 = 1, fibo = 0;
    n++;

    try
    {
        for (int i = 1; i < n; i++)
        {
            n1 = n2;
            n2 = fibo;
            fibo = n1 + n2;
        }
    }
    catch {}

    return fibo;
}

现在它始终打印出 0.69 ...- 实际上运行得更快!但为什么?

注意:我使用 Release 配置对它进行了编译,并直接运行 EXE 文件(在 Visual Studio 外部)。

编辑: 乔恩 · 斯凯特(Jon Skeet)的出色分析表明,在这种特定情况下,尝试捕获以某种方式导致 x86 CLR 以更有利的方式使用 CPU 寄存器(而且我认为我们尚未理解原因)。我确认了乔恩(Jon)的发现,即 x64 CLR 没有这种区别,并且它比 x86 CLR 更快。我还测试了在 Fibo 方法内部使用int类型而不是long类型,然后 x86 CLR 与 x64 CLR 一样快。


更新:看起来这个问题已由罗斯林(Roslyn)解决。同一台机器,相同的 CLR 版本 - 使用 VS 2013 编译时问题仍然如上,但使用 VS 2015 编译时问题不再存在。

答案

一位专门研究堆栈使用优化的Roslyn工程师对此进行了研究,并向我报告 C#编译器生成本地变量存储的方式与JIT编译器进行注册的方式之间的交互似乎存在问题。在相应的 x86 代码中进行调度。结果是在本地的加载和存储上生成次优代码。

由于我们所有人都不清楚的某些原因,当 JITter 知道该块处于 try-protected 区域中时,可以避免有问题的代码生成路径。

这很奇怪。我们将与 JITter 团队进行跟进,看看是否可以输入错误,以便他们可以解决此问题。

此外,我们正在努力改进 Roslyn 的 C#和 VB 编译器算法,以确定何时可以使本地人成为 “临时” 人 - 即只是将其压入并弹出堆栈,而不是在堆栈上分配特定位置用于激活的持续时间。我们相信 JITter 将能够更好地进行寄存器分配,如果我们能更好地提示何时可以使本地人 “死” 的话,那我们将做得更好。

感谢您引起我们的注意,并为您的怪异行为致歉。

好吧,我对事情的计时方式看起来很讨厌。仅对整个循环进行计时会更明智:

var stopwatch = Stopwatch.StartNew();
for (int i = 1; i < 100000000; i++)
{
    Fibo(100);
}
stopwatch.Stop();
Console.WriteLine("Elapsed time: {0}", stopwatch.Elapsed);

这样一来,您就不会受到小巧的时序,浮点运算和累积误差的支配。

进行更改后,请查看 “非捕获” 版本是否仍比 “捕获” 版本慢。

编辑:好的,我自己尝试过 - 我看到了相同的结果。很奇怪。我想知道 try / catch 是否禁用了一些错误的内联,但是使用[MethodImpl(MethodImplOptions.NoInlining)]却无济于事...

基本上,您需要在 cordbg 下查看优化的 JITted 代码,我怀疑...

编辑:更多信息:

  • 将 try / catch 放在n++;周围n++;线仍然可以提高性能,但幅度不比整个程序块高
  • 如果您捕获到特定的异常(在我的测试中为ArgumentException ),它仍然非常快
  • 如果在 catch 块中打印异常,它仍然会很快
  • 如果将异常重新抛出到 catch 块中,它又会变慢
  • 如果您使用 finally 块而不是 catch 块,它又会变慢
  • 如果您同时使用 finally 块 catch 块,则速度很快

奇怪的...

编辑:好的,我们有反汇编...

这是使用 C#2 编译器和. NET 2(32 位)CLR,与 mdbg 进行反汇编(因为我的计算机上没有 cordbg)。即使在调试器下,我仍然看到相同的性能效果。快速版本使用try块围绕变量声明和 return 语句之间的所有内容,仅带有catch{}处理函数。显然,除了没有 try / catch 之外,慢速版本是相同的。在这两种情况下,调用代码(即 Main)是相同的,并且具有相同的程序集表示形式(因此,这不是内联的问题)。

快速版本的反汇编代码:

[0000] push        ebp
 [0001] mov         ebp,esp
 [0003] push        edi
 [0004] push        esi
 [0005] push        ebx
 [0006] sub         esp,1Ch
 [0009] xor         eax,eax
 [000b] mov         dword ptr [ebp-20h],eax
 [000e] mov         dword ptr [ebp-1Ch],eax
 [0011] mov         dword ptr [ebp-18h],eax
 [0014] mov         dword ptr [ebp-14h],eax
 [0017] xor         eax,eax
 [0019] mov         dword ptr [ebp-18h],eax
*[001c] mov         esi,1
 [0021] xor         edi,edi
 [0023] mov         dword ptr [ebp-28h],1
 [002a] mov         dword ptr [ebp-24h],0
 [0031] inc         ecx
 [0032] mov         ebx,2
 [0037] cmp         ecx,2
 [003a] jle         00000024
 [003c] mov         eax,esi
 [003e] mov         edx,edi
 [0040] mov         esi,dword ptr [ebp-28h]
 [0043] mov         edi,dword ptr [ebp-24h]
 [0046] add         eax,dword ptr [ebp-28h]
 [0049] adc         edx,dword ptr [ebp-24h]
 [004c] mov         dword ptr [ebp-28h],eax
 [004f] mov         dword ptr [ebp-24h],edx
 [0052] inc         ebx
 [0053] cmp         ebx,ecx
 [0055] jl          FFFFFFE7
 [0057] jmp         00000007
 [0059] call        64571ACB
 [005e] mov         eax,dword ptr [ebp-28h]
 [0061] mov         edx,dword ptr [ebp-24h]
 [0064] lea         esp,[ebp-0Ch]
 [0067] pop         ebx
 [0068] pop         esi
 [0069] pop         edi
 [006a] pop         ebp
 [006b] ret

慢速版本的反汇编代码:

[0000] push        ebp
 [0001] mov         ebp,esp
 [0003] push        esi
 [0004] sub         esp,18h
*[0007] mov         dword ptr [ebp-14h],1
 [000e] mov         dword ptr [ebp-10h],0
 [0015] mov         dword ptr [ebp-1Ch],1
 [001c] mov         dword ptr [ebp-18h],0
 [0023] inc         ecx
 [0024] mov         esi,2
 [0029] cmp         ecx,2
 [002c] jle         00000031
 [002e] mov         eax,dword ptr [ebp-14h]
 [0031] mov         edx,dword ptr [ebp-10h]
 [0034] mov         dword ptr [ebp-0Ch],eax
 [0037] mov         dword ptr [ebp-8],edx
 [003a] mov         eax,dword ptr [ebp-1Ch]
 [003d] mov         edx,dword ptr [ebp-18h]
 [0040] mov         dword ptr [ebp-14h],eax
 [0043] mov         dword ptr [ebp-10h],edx
 [0046] mov         eax,dword ptr [ebp-0Ch]
 [0049] mov         edx,dword ptr [ebp-8]
 [004c] add         eax,dword ptr [ebp-1Ch]
 [004f] adc         edx,dword ptr [ebp-18h]
 [0052] mov         dword ptr [ebp-1Ch],eax
 [0055] mov         dword ptr [ebp-18h],edx
 [0058] inc         esi
 [0059] cmp         esi,ecx
 [005b] jl          FFFFFFD3
 [005d] mov         eax,dword ptr [ebp-1Ch]
 [0060] mov         edx,dword ptr [ebp-18h]
 [0063] lea         esp,[ebp-4]
 [0066] pop         esi
 [0067] pop         ebp
 [0068] ret

在每种情况下, *表示调试器在简单的 “逐步进入” 中输入的位置。

编辑:好的,我现在看了一下代码,我想我可以看到每个版本的工作原理了…… 我相信较慢的版本会更慢,因为它使用较少的寄存器和更多的堆栈空间。对于较小的n值,可能会更快 - 但是,如果循环占用了大部分时间,则速度会变慢。

可能 try / catch 块会强制保存和还原更多的寄存器,因此 JIT 也将这些寄存器用于循环... 这恰好可以提高整体性能。对于 JIT, 不要在 “正常” 代码中使用尽可能多的寄存器是否合理,尚不明确。

编辑:刚在我的 x64 机器上尝试过。在 64 位 CLR 的速度快得多(约 3-4 倍的速度)比该代码在 x86 CLR,并在 x64 的 try / catch 块不会使一个显着的差异。

乔恩(Jon)的反汇编表明,两个版本之间的区别在于,快速版本使用一对寄存器( esi,edi )存储慢速版本所没有的局部变量之一。

对于包含 try-catch 块的代码与不包含 try-catch 块的代码,JIT 编译器对寄存器的使用做出不同的假设。这导致它做出不同的寄存器分配选择。在这种情况下,这有利于使用 try-catch 块的代码。不同的代码可能导致相反的效果,因此我不认为这是通用的加速技术。

最后,很难确定哪些代码将以最快的速度运行。诸如寄存器分配之类的东西以及影响它的因素都是如此低的实现细节,我看不到任何特定技术如何可靠地产生更快的代码。

例如,考虑以下两种方法。他们改编自一个真实的例子:

interface IIndexed { int this[int index] { get; set; } }
struct StructArray : IIndexed { 
    public int[] Array;
    public int this[int index] {
        get { return Array[index]; }
        set { Array[index] = value; }
    }
}

static int Generic<T>(int length, T a, T b) where T : IIndexed {
    int sum = 0;
    for (int i = 0; i < length; i++)
        sum += a[i] * b[i];
    return sum;
}
static int Specialized(int length, StructArray a, StructArray b) {
    int sum = 0;
    for (int i = 0; i < length; i++)
        sum += a[i] * b[i];
    return sum;
}

一个是另一个的通用版本。用StructArray替换通用类型将使方法完全相同。因为StructArray是值类型,所以它获得了自己的泛型方法的编译版本。然而,实际的运行时间比专门方法的要长得多,但仅适用于 x86。对于 x64,时序几乎相同。在其他情况下,我也观察到 x64 的差异。

这看起来像是内联变坏的情况。在 x86 内核上,抖动具有 ebx,edx,esi 和 edi 寄存器,可用于通用目的存储局部变量。 ecx 寄存器可以通过静态方法使用,而不必存储this 。计算经常需要 eax 寄存器。但是这些是 32 位寄存器,对于 long 类型的变量,必须使用一对寄存器。 edx:eax 用于计算,而 edi:ebx 用于存储。

这是慢版本在反汇编中的突出表现,没有使用 edi 和 ebx。

当抖动找不到足够的寄存器来存储局部变量时,它必须生成代码以从堆栈帧加载和存储它们。这降低了代码速度,阻止了名为 “寄存器重命名” 的处理器优化,这是一种内部处理器核心优化技巧,它使用寄存器的多个副本并允许超标量执行。即使它们使用相同的寄存器,它也允许多个指令同时运行。没有足够的寄存器是 x86 内核上的一个常见问题,在 x64 内核中有 8 个额外的寄存器(r9 至 r15)解决。

抖动将尽力应用其他代码生成优化,它将尝试内联 Fibo()方法。换句话说,不要调用该方法,而是在 Main()方法中为该方法内联生成代码。非常重要的优化是,免费提供 C#类的属性,使它们具有字段性能。它避免了进行方法调用和设置其堆栈框架的开销,节省了几纳秒的时间。

有几条规则可以精确确定何时可以内联方法。它们没有确切记录,但已在博客文章中提及。一个规则是,当方法主体太大时,它不会发生。这样做会抵消内联的好处,它会生成太多的代码,这些代码也不适合 L1 指令高速缓存。此处适用的另一条硬规则是,当一个方法包含 try / catch 语句时,将不会对其进行内联。一个异常背后的背景是异常的实现细节,它们背负于 Windows 对基于堆栈框架的 SEH(结构异常处理)的内置支持。

可以通过使用此代码来推断寄存器分配算法在抖动中的一种行为。它似乎知道抖动何时试图内联方法。一种似乎使用的规则是,只有 edx:eax 寄存器对可用于具有 long 类型局部变量的内联代码。但不是 edi:ebx。毫无疑问,因为这将不利于调用方法的代码生成,因此 edi 和 ebx 都是重要的存储寄存器。

因此,您可以获得快速版本,因为抖动事先知道方法主体包含 try / catch 语句。它知道它永远无法内联,因此很容易使用 edi:ebx 来存储 long 变量。您之所以选择慢速版本,是因为抖动不知道内联是行不通的。它仅生成方法主体的代码后才发现。

缺点是它没有返回并重新生成该方法的代码。考虑到运行的时间限制,这是可以理解的。

在 x64 上不会发生这种减速,因为其中一个有 8 个以上的寄存器。另一个原因是因为它可以在一个寄存器中存储一个 long(例如 rax)。当使用 int 而不是 long 时,不会发生减慢,因为抖动在选择寄存器时具有更大的灵活性。

我本来将其作为评论,因为我确实不确定是否可能是这种情况,但是正如我记得的那样,try / except 语句并不涉及对垃圾处理机制的修改。编译器的工作方式是,它以递归方式从堆栈中清除对象内存分配。在这种情况下,可能没有要清除的对象,或者 for 循环可能构成垃圾回收机制认识到足以实施另一种回收方法的闭包。可能不是,但是我认为值得一提,因为我没有看到它在其他地方讨论过。