C# 与 C++ 的性能——为什么 .NET 不执行最基本的优化(如死代码消除)？

Question

我严重怀疑 C# 或 .NET JIT 编译器是否执行任何有用的优化，更不用说它们是否真的与 C++ 编译器中最基本的竞争。

考虑一下这个极其简单的程序，我很方便地把它做成在 C++ 和 C# 中都有效:

#if __cplusplus
#else
static class Program
{
#endif
    static void Rem()
    {
        for (int i = 0; i < 1 << 30; i++) ;
    }
#if __cplusplus
    int main()
#else
    static void Main()
#endif
    {
        for (int i = 0; i < 1 << 30; i++)
            Rem();
    }
#if __cplusplus
#else
}
#endif

当我在最新版本的 C# (VS 2013) 中以 Release模式编译和运行它时，它不会在任何合理的时间内终止。

编辑:这是另一个例子:

static class Program
{
    private static void Test2() { }

    private static void Test1()
    {
#if TEST
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
        Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2(); Test2();
#else
        Test2();
#endif
    }

    static void Main()
    {
        for (int i = 0; i < 0x7FFFFFFF; i++)
            Test1();
    }
}

当我运行这个时，如果 TEST 被定义，它需要 很多 更长的时间，即使一切都是空操作和 Test2应该内联。

即使是最古老的 C++ 编译器我也能掌握，但是，优化一切，让程序立即返回。

是什么阻止了 .NET JIT 优化器进行如此简单的优化？为什么？

Answer 1

.NET JIT 是一个糟糕的编译器，这是事实。幸运的是，一个新的 JIT (RyuJIT) 和一个似乎基于 VC 编译器的 NGEN 正在开发中(我相信这是 Windows Phone cloud compiler 使用的)。

虽然它是一个非常简单的编译器，但它确实内联小函数并在一定程度上消除了无副作用的循环。这一切都不好，但它确实发生了。

在我们进入详细调查结果之前，请注意 x86 和 x64 JIT 是不同的代码库，执行方式不同并且存在不同的错误。

---

测试 1:

您在 32 位模式下以 Release模式运行程序。我可以在 .NET 4.5 上以 32 位模式重现您的发现。是的，这很尴尬。

但在 64 位模式下，第一个示例中的 Rem 是内联的，并且两个嵌套循环的最内层被移除:

我已经标记了三个循环指令。外环还在。我认为这在实践中并不重要，因为您很少有两个嵌套的死循环。

注意，循环展开了 4 次，然后展开的迭代被折叠成一个迭代(展开产生 i += 1; i+= 1; i+= 1; i+= 1;并被折叠为 i += 4;)。当然，可以优化整个循环，但 JIT 确实执行了实践中最重要的事情:展开循环和简化代码。

我还在 Main 中添加了以下内容，以便于调试:

    Console.WriteLine(IntPtr.Size); //verify bitness
    Debugger.Break(); //attach debugger

---

测试 2:

我无法在 32 位或 64 位模式下完全重现您的发现。在所有情况下，Test2 都内联到 Test1 中，使其成为一个非常简单的函数:

Main 在循环中调用 Test1 因为 Test1 太大而无法内联(因为非简化的大小很重要，因为方法是 JIT'单独编辑)。

如果在 Test1 中只有一个 Test2 调用，那么这两个函数都足够小，可以内联。这使 Main 的 JIT 能够发现在该代码中根本没有做任何事情。

---

最终答案:我希望我能对正在发生的事情有所了解。在这个过程中，我确实发现了一些重要的优化。 JIT 只是不是很彻底和完整。如果相同的优化只是在第二次相同的传递中执行，那么这里可以简化更多。但是大多数程序只需要一次通过所有的简化器。我同意 JIT 团队在这里所做的选择。

那么，为什么 JIT 如此糟糕？一方面是它必须很快，因为 JITing 对延迟敏感。另一部分是它只是一个原始的JIT，需要更多的投资。