在调用c ++函数时,CLR如何避免thunking？

Question

MSDN声明:

无论使用何种互操作技术,每次托管函数调用非托管函数时都需要特殊的转换序列(称为thunks),反之亦然.这些thunk是由Visual C++编译器自动插入的,但重要的是要记住,累积起来,这些转换在性能方面可能很昂贵.

然而,CLR肯定会一直调用C++和Win32函数.为了处理文件/网络/窗口以及几乎任何其他内容,必须调用非托管代码.它是如何摆脱分块惩罚的？

这是一个用C++/CLI编写的实验,可能有助于描述我的问题:

#define REPS 10000000

#pragma unmanaged
void go1() {
    for (int i = 0; i < REPS; i++)
        pow(i, 3);
}
#pragma managed
void go2() {
    for (int i = 0; i < REPS; i++)
        pow(i, 3);
}
void go3() {
    for (int i = 0; i < REPS; i++)
        Math::Pow(i, 3);
}

public ref class C1 {
public:
    static void Go() {
        auto sw = Stopwatch::StartNew();
        go1();
        Console::WriteLine(sw->ElapsedMilliseconds);
        sw->Restart();
        go2();
        Console::WriteLine(sw->ElapsedMilliseconds);
        sw->Restart();
        go3();
        Console::WriteLine(sw->ElapsedMilliseconds);
    }
};

//Go is called from a C# app

结果是(一致地):

405 (go1 - pure C++)
818 (go2 - managed code calling C++)
289 (go3 - pure managed)

为什么go3比go1更快有点神秘,但这不是我的问题.我的问题是,我们从go1&go2看到,thunking惩罚增加了400ms.go3如何摆脱这种惩罚,因为它调用C++来进行实际计算？

即使这个实验由于某种原因无效,我的问题仍然存在 - 每次调用C++/Win32时,CLR是否真的有一个thunking惩罚？

Answer 1

基准测试是一种黑色艺术,你在这里得到了一些误导性的结果.运行Release版本非常重要,如果你这样做,那么你现在会注意到go1()不再需要时间了.本机代码优化器具有它的特殊知识,如果你不使用它的结果,那么它完全消除它.

您必须更改代码才能获得可靠的结果.首先在Go()测试体周围放置一个循环,重复至少20次.这消除了jitting和缓存开销,并有助于查看大的标准偏差.敲掉REPS 0,这样你就不用等太久了.赞成工具>选项>调试>常规,"抑制JIT优化"未选中.更改代码,我建议:

__declspec(noinline)
double go1() {
    double sum = 0;
    for (int i = 0; i < REPS; i++)
        sum += pow(i, 3);
    return sum;
}

注意sum变量如何强制优化器保持调用,使用__declspec可以防止删除整个函数并避免污染Go()体.对go2和go3执行相同操作,使用[MethodImpl(MethodImplOptions :: NoInlining)].

我在笔记本电脑上看到的结果:x64:75,84,84,x86:73,89,89 + 5/-3毫秒.

工作中有三种不同的机制:

• go1()代码生成正如您在本机代码中所期望的那样,在x64模式下直接调用__libm_sse2_pow_precise()CRT函数.这里没什么了不起的,除了在Release版本中删除它的风险.
• go2()使用你询问的thunk.文档对于thunking有点过于恐慌,所需要的只是代码在堆栈上编写cookie,以防止垃圾收集器在查找对象根时陷入非托管堆栈帧.当它还必须转换函数参数和/或返回值时,它可能更昂贵,但这不是这里的情况.抖动优化器不能消除pow()调用,它没有CRT功能的特殊知识.
• go3()使用了一种非常不同的机制,尽管测量结果相似.Math :: Pow()在CLR中是特殊的,它使用所谓的FCall机制.没有thunking,直接从托管代码到编译的C++机器代码.这种微优化在CLR/BCL中非常常见.有些必要,因为它对可能引发异常的参数执行检查,所以会产生额外的开销.此外,抖动优化器没有消除调用的基本原因是,它通常避免了使异常消失的优化.