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

 小老特 发布于 2023-02-12 18:13

我非常怀疑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)中编译并运行它时,它不会在任何合理的时间内终止.

编辑:这是另一个例子:

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优化器能够进行这样简单的优化?为什么?

usr.. 21

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

虽然它是一个非常简单的编译器,它可以内联小函数并在一定程度上消除无副作用的循环.它并不是很好,但它发生了.

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


测试1:

您以32位模式在发布模式下运行程序.我可以使用32位模式在.NET 4.5上重现您的发现.是的,这很令人尴尬.

但是,在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使其成为一个非常简单的功能:

在此输入图像描述

MainTest1在循环中调用,因为Test1它太大而不能内联(因为非简化的大小很重要,因为方法是单独进行JIT的).

当您只有一个Test2呼叫时,Test1两个功能都足够小,无法内联.这使JIT Main能够发现该代码中根本没有进行任何操作.


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

那么为什么JIT如此糟糕?一部分是它必须快速,因为JITing对延迟敏感.另一部分是它只是一个原始的JIT,需要更多的投资.

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

    虽然它是一个非常简单的编译器,它可以内联小函数并在一定程度上消除无副作用的循环.它并不是很好,但它发生了.

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


    测试1:

    您以32位模式在发布模式下运行程序.我可以使用32位模式在.NET 4.5上重现您的发现.是的,这很令人尴尬.

    但是,在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使其成为一个非常简单的功能:

    在此输入图像描述

    MainTest1在循环中调用,因为Test1它太大而不能内联(因为非简化的大小很重要,因为方法是单独进行JIT的).

    当您只有一个Test2呼叫时,Test1两个功能都足够小,无法内联.这使JIT Main能够发现该代码中根本没有进行任何操作.


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

    那么为什么JIT如此糟糕?一部分是它必须快速,因为JITing对延迟敏感.另一部分是它只是一个原始的JIT,需要更多的投资.

    2023-02-12 18:14 回答
撰写答案
今天,你开发时遇到什么问题呢?
立即提问
热门标签
PHP1.CN | 中国最专业的PHP中文社区 | PNG素材下载 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有