为什么 Mono 运行一个简单的方法比 RyuJIT 更慢?

8

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

作为基准测试数据,我准备了一个具有一些随机数值的结构体数组。准备阶段不计入基准测试:

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;
}

我正在使用版本为0.10.12的BenchmarkDotNet,有两个任务:

[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在这里通常会慢一些。但我不明白的是:
考虑到`Direct`方法使用一个非常简单的比较方法,而`Extension`使用了一个带有额外方法调用的方法,为什么Mono运行`Direct`方法比运行`Extension`方法更慢
RyuJIT在这里显示了简单方法的4倍优势。
有人能解释一下吗?

3
除非您能提供生成的汇编代码,否则很难猜测性能为什么是这样的。实际上,我希望这段代码被数组边界检查、内存复制、缓存未命中等所主导,而不是您展示的实际用户代码。另外,您尝试了多少个基准测试?您是否尝试使用更高的迭代次数?结果如何?您展示的是微秒级别的约3%性能差异,对我来说似乎更像是等效而不是其他任何东西。 - Zdeněk Jelínek
1
@ZdeněkJelínek,是的,我尝试了不同的迭代次数(100、1,000、10,000、100,000)。使用BenchmarkDotNet创建的基准测试已经足够聪明(预热阶段、多次迭代等),所以我相信它们。然而,我的问题不在于3%(顺便问一下,你说的3%是什么意思?),而在于Mono和RyuJIT的性能差异:Mono运行ExtensionDirect测试的速度相当快,而RyuJIT运行Direct基准测试的速度比Extension快4倍。您不需要程序集,只需使用BenchmarkDotNet和我提供的代码生成它们即可。 - dymanoid
我想知道在.NET Core 2.1运行时下代码的效率如何。跟RyuJitX64 : .NET Framework 4.7有什么不同吗? - Grzesiek Danowski
1个回答

2

由于没有人想做一些反汇编工作,所以我回答自己的问题。

看起来原因是JIT生成的本地代码,而不是评论中提到的数组边界检查或缓存问题。

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操作来比较float,并使用快速的movaps操作在CPU寄存器之间移动这些float。扩展方法较慢,因为它需要调用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的代码将float转换为double并使用comisd进行比较。此外,在准备返回值时存在奇怪的“转换翻转”float ➞ double ➞ float。还有更多的内存和寄存器之间的移动。这就解释了为什么Mono的简单方法代码比RyuJIT的代码慢。
Extension方法的代码与RyuJIT的代码非常相似,但再次存在着奇怪的转换翻转float ➞ double ➞ float。
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可以为处理浮点数生成更有效的代码。Mono将float视为double并在每次转换值时转换,这也导致CPU寄存器和内存之间的额外值传输。

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


“由于没有人想做一些反汇编工作”是一个有点奇怪的说法。您选择在问题中仅包含源代码,而不是汇编代码,因此我无法为您查看汇编代码的效率。我不知道是否有类似于https://godbolt.org/这样的在线C#编译器探索器,它适用于C、C++、Rust和其他一些语言,而且我也没有Windows。我认为一些其他的x86性能专家也面临同样的困境,他们会查看Stack Overflow上的问题。 - Peter Cordes
1
@PeterCordes,我几个月前问过这个问题,当时我不知道原因是生成的本地代码。一开始我以为可以通过.NET运行时特性等来解释。所以怪我不知道应该立即发布反汇编的本地代码有点奇怪。 - dymanoid
无论如何,Mono的汇编代码真是太糟糕了。如果您能以一种让RyuJIT使用无分支的maxss/minss进行夹紧的方式编写源代码,它可能会更快。(或者如果该值几乎总是在边界内,使得分支预测良好且延迟是瓶颈,则速度会变慢。或者特别是几乎总是越界将使分支与输入结果脱钩,打破数据依赖链。) - Peter Cordes
对于任何微小循环的性能问题,答案都将取决于查看汇编代码以确定循环中的指令来自哪里。如果您发现基准测试与迭代计数呈线性比例关系,则知道时间花费在JIT本地代码中,而不是在启动开销或其他方面。(这就是您想要的)。简而言之:您几乎总是需要发布汇编代码,以便任何人都可以回答为什么一个编译器比另一个编译器更快的单个循环。 - Peter Cordes
@PeterCordes,感谢反馈,但我怀疑我们在 .NET 世界中没有任何办法影响 JIT 在 jit 托管方法时的选择。但我对 Mono 中那个简单方法的可怕性能感到非常惊讶,想要得到一个答案为什么会这样。 - dymanoid
对,我的意思是你需要以不同的方式编写源代码来引导JIT编译器。例如,使用val = (val>min) ? val : min;而不是早期的return语句,以鼓励无分支代码。请参见What is the instruction that gives branchless FP min and max on x86? - Peter Cordes

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接