【问题标题】:Why does Mono run a simple method slower whereas RyuJIT runs it significantly faster?为什么 Mono 运行简单方法的速度较慢,而 RyuJIT 运行速度明显更快?
【发布时间】:2019-01-11 09:09:29
【问题描述】:

出于好奇,我创建了一个简单的基准,但无法解释结果。

作为基准数据,我准备了一个包含一些随机值的结构数组。准备阶段未进行基准测试:

struct Val 
{
    public float val;
    public float min;
    public float max;
    public float padding;
}

const int iterations = 1000;
Val[] values = new Val[iterations];
// fill the array with randoms

基本上,我想比较这两种钳位实现:

static class Clamps
{
    public static float ClampSimple(float val, float min, float max)
    {
        if (val < min) return min;          
        if (val > max) return max;
        return val;
    }

    public static T ClampExt<T>(this T val, T min, T max) where T : IComparable<T>
    {
        if (val.CompareTo(min) < 0) return min;
        if (val.CompareTo(max) > 0) return max;
        return val;
    }
}

这是我的基准测试方法:

[Benchmark]
public float Extension()
{
    float result = 0;
    for (int i = 0; i < iterations; ++i)
    {
        ref Val v = ref values[i];
        result += v.val.ClampExt(v.min, v.max);
    }

    return result;
}

[Benchmark]
public float Direct()
{
    float result = 0;
    for (int i = 0; i < iterations; ++i)
    {
        ref Val v = ref values[i];
        result += Clamps.ClampSimple(v.val, v.min, v.max);
    }

    return result;
}

我正在使用 BenchmarkDotNet 0.10.12 版和两个作业:

[MonoJob]
[RyuJitX64Job]

这些是我得到的结果:

BenchmarkDotNet=v0.10.12, OS=Windows 7 SP1 (6.1.7601.0)
Intel Core i7-6920HQ CPU 2.90GHz (Skylake), 1 CPU, 8 logical cores and 4 physical cores
Frequency=2836123 Hz, Resolution=352.5940 ns, Timer=TSC
  [Host]    : .NET Framework 4.7 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3062.0
  Mono      : Mono 5.12.0 (Visual Studio), 64bit
  RyuJitX64 : .NET Framework 4.7 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3062.0


    Method |       Job | Runtime |      Mean |     Error |    StdDev |
---------- |---------- |-------- |----------:|----------:|----------:|
 Extension |      Mono |    Mono | 10.860 us | 0.0063 us | 0.0053 us |
    Direct |      Mono |    Mono | 11.211 us | 0.0074 us | 0.0062 us |
 Extension | RyuJitX64 |     Clr |  5.711 us | 0.0014 us | 0.0012 us |
    Direct | RyuJitX64 |     Clr |  1.395 us | 0.0056 us | 0.0052 us |

我可以接受 Mono 在这里一般来说有点慢。但我不明白的是:

为什么 Mono 运行 Direct 方法Extension 请记住 Direct 使用非常简单的比较方法,而 Extension 使用带有额外方法调用的方法?

RyuJIT 在这里展示了简单方法的 4 倍优势。

谁能解释一下?

【问题讨论】:

  • 除非您能够向我们提供生成的程序集,否则很难猜测性能为何如此。我实际上希望此代码由数组绑定检查、内存复制、缓存未命中等主导,而不是您显示的实际用户代码。另外,您尝试了多少基准测试?您是否尝试过更高的迭代次数?结果如何?您所展示的是在微秒级别上约 3% 的性能差异,在我看来,这比其他任何东西都更等效。
  • @ZdeněkJelínek,是的,我尝试了不同的迭代次数 (100, 1.000, 10.000, 100.000) 。使用BenchmarkDotNet 创建的基准测试已经足够聪明(热身阶段、多次迭代等),所以我相信它们。然而,我的问题不是关于 3%(顺便说一句,3% 是什么意思?),而是关于 Mono 和 RyuJIT 性能之间的差异:Mono 运行 ExtensionDirect 测试速度相当快,而 RyuJIT 运行 @ 987654333@ 基准测试比Extension 快 4 倍。您不需要这些程序集,只需使用 BenchmarkDotNet 和我提供的代码自己生成它们。
  • 我想知道代码在 .NET Core 2.1 运行时如何高效。与 RyuJitX64 : .NET Framework 4.7 有什么不同吗?

标签: c# mono benchmarking ryujit benchmarkdotnet


【解决方案1】:

由于没有人想做一些反汇编的东西,我回答我自己的问题。

原因似乎是 JIT 生成的本机代码,而不是 cmets 中提到的数组边界检查或缓存问题。

RyuJIT 为ClampSimple 方法生成了一个非常高效的代码:

    vucomiss xmm1,xmm0
    jbe     M01_L00
    vmovaps xmm0,xmm1
    ret

M01_L00:
    vucomiss xmm0,xmm2
    jbe     M01_L01
    vmovaps xmm0,xmm2
    ret

M01_L01:
    ret

它使用 CPU 的原生 ucomiss 操作来比较 floats,并使用快速 movaps 操作在 CPU 的寄存器之间移动这些 floats。

扩展方法比较慢,因为它有几个函数调用System.Single.CompareTo(System.Single),这里是第一个分支:

lea     rcx,[rsp+30h]
vmovss  dword ptr [rsp+38h],xmm1
call    mscorlib_ni+0xda98f0
test    eax,eax
jge     M01_L00
vmovss  xmm0,dword ptr [rsp+38h]
add     rsp,28h
ret

让我们看看 Mono 为 ClampSimple 方法生成的原生代码:

    cvtss2sd    xmm0,xmm0  
    movss       xmm1,dword ptr [rsp+8]  
    cvtss2sd    xmm1,xmm1  
    comisd      xmm1,xmm0  
    jbe         M01_L00  
    movss       xmm0,dword ptr [rsp+8]  
    cvtss2sd    xmm0,xmm0  
    cvtsd2ss    xmm0,xmm0  
    jmp         M01_L01 

M01_L00: 
    movss       xmm0,dword ptr [rsp]  
    cvtss2sd    xmm0,xmm0  
    movss       xmm1,dword ptr [rsp+10h]  
    cvtss2sd    xmm1,xmm1  
    comisd      xmm1,xmm0  
    jp          M01_L02
    jae         M01_L02  
    movss       xmm0,dword ptr [rsp+10h]  
    cvtss2sd    xmm0,xmm0  
    cvtsd2ss    xmm0,xmm0  
    jmp         M01_L01

M01_L02:
    movss       xmm0,dword ptr [rsp]  
    cvtss2sd    xmm0,xmm0  
    cvtsd2ss    xmm0,xmm0  

M01_L01:
    add         rsp,18h  
    ret 

Mono 的代码将floats 转换为doubles 并使用comisd 进行比较。此外,在准备返回值时,还有奇怪的“转换翻转”floatdoublefloat。而且在内存和寄存器之间还有更多的移动。这就解释了为什么 Mono 的简单方法的代码比 RyuJIT 的要慢。

Extension 方法代码与 RyuJIT 的代码非常相似,但同样有奇怪的转换翻转 floatdoublefloat

movss       xmm0,dword ptr [rbp-10h]  
cvtss2sd    xmm0,xmm0  
movsd       xmm1,xmm0  
cvtsd2ss    xmm1,xmm1  
lea         rbp,[rbp]  
mov         r11,2061520h  
call        r11  
test        eax,eax  
jge         M0_L0 
movss       xmm0,dword ptr [rbp-10h]  
cvtss2sd    xmm0,xmm0  
cvtsd2ss    xmm0,xmm0
ret

RyuJIT 似乎可以生成更高效的代码来处理floats。 Mono 将 floats 视为 doubles 并每次转换值,这也会导致 CPU 寄存器和内存之间的额外值传输。

请注意,所有这些仅对 Windows x64 有效。我不知道这个基准在 Linux 或 Mac 上的表现如何。

【讨论】:

  • 既然没人想做一些反汇编的东西,这句话有点奇怪。您选择在您的问题中仅包含源,而不是 asm,因此我无法为您查看 asm 的效率。我不知道 C# 的在线编译器-探索器等价物,如 godbolt.org 有 C、C++、Rust 和其他一些语言,而且我没有 Windows。我认为,其他一些研究 SO 问题的 x86 性能专家也处于同一条船上。
  • @PeterCordes,几个月前我问过这个问题,我不知道原因是生成的本机代码。我首先认为它可以通过 .NET 运行时特性等来解释。所以怪我不知道我应该立即发布反汇编的本机代码,这有点奇怪。
  • 无论如何,哇,这真是来自 Mono 的可怕 asm。如果您可以以使 RyuJIT 使用无分支 maxss / minss 进行钳位的方式编写源代码,它可能会更快。 (或者如果该值几乎总是在边界内,因此分支预测良好,并且延迟是瓶颈,则速度会变慢。或者尤其是几乎总是 out 边界会使分支将结果与输入解耦,从而破坏数据依赖链。)
  • 对于小循环的任何性能问题的答案都将归结为查看 asm 以找出循环中的指令来自何处。如果您发现基准与迭代次数成线性关系,那么您就知道时间花在了 JITed 本机代码上,而不是启动开销之类的东西上。 (这就是你想要的)。 TL:DR:您几乎总是需要向任何人发布 asm,以回答为什么一个编译器在单个循环中比另一个编译器快。
  • @PeterCordes,感谢您的反馈,但我怀疑我们在 .NET 世界中是否有任何方法可以影响 JIT 在 jitting 托管方法时选择的内容。但我对 Mono 中这种简单方法的糟糕性能感到非常惊讶,并想知道为什么会这样。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-10-27
相关资源
最近更新 更多