首页   技术笔记   网址导航   Json在线解析   二维码   Ip地址查询   在线流程图  
新用户注册 | 会员登录
当前位置:  开发笔记 > 编程语言 > 正文

C++比C#快多少？

作者：放ch养奶牛 | 2023-09-04 19:20
如何解决《C++比C#快多少？》经验，为你挑选了17个好方法。

或者它现在反过来了？

从我所听到的有些领域,C#证明比C++更快,但我从来没有勇气自己测试它.

你们中的任何一个人都可以详细解释这些差异,或者将我指向正确的地方以获取相关信息.



1> Martin Probs..：

没有严格的理由说明基于字节码的语言(如C#或Java)具有JIT不能像C++代码一样快.但是,C++代码在很长一段时间内都显着提高了速度,而且在很多情况下今天仍然如此.这主要是由于更高级的JIT优化实现起来很复杂,而真正酷的优化只是刚刚到来.

因此,在许多情况下,C++更快.但这只是答案的一部分.C++实际上更快的情况是高度优化的程序,专家程序员彻底优化了代码的地狱.这不仅非常耗时(并且因此昂贵),而且还通常由于过度优化而导致错误.

另一方面,解释语言中的代码在运行时的更高版本(.NET CLR或Java VM)中变得更快,而无需执行任何操作.JIT编译器可以做很多有用的优化,这些优化在带有指针的语言中根本不可能.此外,一些人认为垃圾收集通常应该与手动内存管理一样快或者更快,并且在许多情况下它是.您通常可以在C++或C中实现并实现所有这些功能,但它会更加复杂且容易出错.

正如唐纳德克努特所说,"过早优化是所有邪恶的根源".如果您确实知道您的应用程序将主要包含非常高性能的算法,并且它将成为瓶颈,并且它在C++中肯定会更快,并且您确信C++不会与您的其他C++冲突要求,去C++.在任何其他情况下,专注于首先以最适合您的语言正确实现您的应用程序,然后在运行速度太慢时找到性能瓶颈,然后考虑如何优化代码.在最坏的情况下,您可能需要通过外部函数接口调用C代码,因此您仍然可以使用较低级别的语言编写关键部分.

请记住,优化正确的程序相对容易,但更难以纠正优化的程序.

给出速度优势的实际百分比是不可能的,这在很大程度上取决于您的代码.在许多情况下,编程语言实现甚至不是瓶颈.请参考http://benchmarksgame.alioth.debian.org/上的基准测试,因为这些基本上是测试算术代码,很可能与您的代码完全不同.

解释语言中的代码在运行时的更高版本中变得更快由更好版本的编译器编译的代码也会变得更快.
"但也常常因过度优化而导致错误." [迫切需要引用].我在国家实验室工作,我们优化了我们的代码.这通常不会导致错误的代码.
事实上,至少有一个原因:JIT需要快速,并且不能花时间在C++编译器可用的各种高级优化上.
"优化正确的程序相对容易,但更难以纠正优化的程序."
英格:不确定你是否在正确的轨道上.是的,C#是用另一种语言实现的,但JIT编译器正在生成机器代码,因此它不是解释语言.因此它不受其C++实现的限制.我不确定为什么你认为添加一些经理固有地使它更快.
@Matin York:但新的JIT也可以更快地执行旧的程序集,新的编译器没有新的编译就没用了;)
@Eonil除了它需要重新部署？对于服务器系统,确保继续使用具有更高级优化的更现代的编译器重新编译软件.但对于消费者市场,在发布新版本之前通常无法做到这一点.使用.NET 8年前编译的程序,由于在新的.NET Framework中进行了优化,可能会突然变得更快.
请注意,如果sb必须对性能关键算术进行编码,最好在Fortran中对其进行编码,否则请向C++编译器提供数据不会被其他指针别名的提示.
@Aidiakapi JIT意味着您在运行时环境中有一个编译器.没有理由不用新的编译器重新编译C++程序.
*“没有严格的理由，为什么具有JIT的基于字节码的语言（如C＃或Java）不能与C ++代码一样快。” *当然可以。一方面，与AoT编译器相比，JIT编译器的代码编译时间有限。这足以使他们处于不利地位。
@Nemanja Trifunovic：取决于您的情况。在服务器应用程序中，JIT并不需要太快-您可以很好地分摊时间成本，并对代码进行增量增强。
我喜欢C++,但这可能是因为我编写的游戏中几乎所有东西都是疯狂的数学重量(物理,碰撞,加权网格变形 - 这样的东西.)
C#是用C++编写的,所以我看不出它如何以比C++更快的速度更快.最好的C#只能和C++一样快.然后,.NET有一个托管堆,托管线程池等,它可以使你的代码比没有这些管理器的C++程序更快 - 但这些是.NET的特性而不是C#编程语言本身.
实际上，主要要点是某些事情不能在C＃中有效地完成，而可以在C ++中有效地完成，例如AMP也许只是暂时的，但目前是这样。
我认为C++编译器生成的代码不一定比C#编译器生成的代码更快(或更慢).我认为C++比C#更能控制代码的性能特征.

2> mattlant..：

C#可能不会更快,但它会让你/我更快.这是我做的最重要的衡量标准.:)

哈哈,拉里沃尔对这个话题有一个很好的引用.他正在谈论perl,但可以考虑所有涉及语言和性能的讨论:"早期的计算机语言,如Fortran和C,旨在有效利用昂贵的计算机硬件.相比之下,Perl旨在有效利用昂贵的计算机程序员"
1."C#比C++快得多"2."它不可能是真的"1."当然可以"2"多少？" 1."通常3-4个月"
对于真正依赖于你使用的库的C++,当你谈论生产力时,C#通常不会更快

3> Konrad Rudol..：

它的五个橙子更快.或者更确切地说:没有(正确的)一揽子答案.C++是一种静态编译的语言(但是,也有配置文件引导优化),C#在JIT编译器的帮助下运行.存在很多差异,诸如"快多快"的问题无法回答,甚至不能达到数量级.

你有没有证据支持你的五个橘子声称？我的实验最多都指向2个橙子,在进行模板元编程时有3个芒果改进.
在酵母中,他并没有把它的速度提高到更高的速度.
根据我的经验,它相当于5.2个橙子.但这取决于您使用的水果计量表.
更新,StackOverflow本身搞砸并处理评论效率低下,因此香蕉少(300香蕉比应该更糟):https://meta.stackexchange.com/questions/254534/count-is-wrong-in-more-to-go - 用于-评论

4> U007D..：

首先,我将通过陈述:不同意对此问题的部分接受(以及良好的投票)答案:

实际上有很多原因导致JITted代码运行速度慢于正确优化的C++(或其他没有运行时开销的语言)程序,包括:

根据定义,在运行时花在JITting代码上的计算周期不可用于程序执行.

在抖动任何热的路径将与您的CPU中的指令和数据缓存代码竞争.我们知道缓存在性能方面占主导地位,而C++等本地语言根据定义没有这种类型的争用.

运行时优化的时间预算必然是多比的更多的限制编译时优化器(如另一个评论指出)

底线:最终,你将几乎肯定能在C创建一个更快的实现++比你在C#中能.

现在,有了这样说,实际上还有多快不可量化,因为变量太多:任务,问题域,硬件,实现质量以及许多其他因素.您将对场景运行测试以确定性能差异,然后确定是否值得额外的工作量和复杂性.

这是一个非常漫长而复杂的主题,但我觉得为了完整起见,值得一提的是C#的运行时优化器非常出色,并且能够在运行时执行某些动态优化,这些优化在C++编译时是不可用的(静态)优化器.即便如此,优势仍然通常在本机应用程序的法庭上,但动态优化器是上面给出的" 几乎肯定"限定符的原因.

-

在相对表现方面,我也被其他一些答案所看到的数字和讨论所打扰,所以我想我会在同一时间为我上面的陈述提供一些支持.

这些基准测试的问题很大一部分就是你不能像编写C#一样编写C++代码并期望获得有代表性的结果(例如,在C++中执行数千个内存分配会给你带来可怕的数字.)

相反,我写了稍微更惯用的C++代码,并与提供的C#代码@Wiory进行了比较.我对C++代码所做的两个主要更改是:

1)使用了vector :: reserve()

2)将2d数组展平为1d以实现更好的缓存局部性(连续块)

C#(.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

运行时间(Release):Init:124ms,填充:165ms

C++ 14(Clang v3.8/C2)

#include 
#include 

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

运行时间(释放):初始值:398μs(是的,那是微秒),填充:152ms

总运行时间:C#:289ms,C++ 152ms(大约快90%)

意见

将C#实现更改为相同的1d数组实现,产生Init:40ms,填充:171ms,总计:211ms(C++仍然快了近40%).

在C++中设计和编写"快速"代码要比在任何一种语言中编写"常规"代码要困难得多.

它(或许)很容易在C++中表现不佳; 我们看到了无保留的向量性能.而且有很多像这样的陷阱.

当您考虑运行时发生的所有事情时,C#的性能相当惊人.并且该性能相对容易访问.

比较C++和C#的性能的更多轶事数据:https://benchmarksgame.alioth.debian.org/u64q/compare.php？lang = gpp&lang2 = csharpcore

最重要的是,C++为您提供了更多的性能控制.你想用指针吗？参考？堆栈内存？堆？动态多态或消除静态多态的vtable的运行时开销(通过模板/ CRTP)？在C++中,你必须......呃,自己做出所有这些选择(以及更多),理想情况下,你的解决方案最能解决你正在解决的问题.

问问自己你是否真的想要或需要这种控制,因为即使是上面的小例子,你也可以看到虽然性能有了显着提高,但它需要更深入的投资才能获得.

@Quonux感谢您的评论.当然,这不是一个"真正的计划".基准测试的重点是重构本页其他地方提供的C#基准测试,证明JITted代码在某种程度上比原生代码更快 - 事实并非如此,基准测试可能会误导新人.
支持有意义的基准;-)
@Quonux你为什么要这样写？像你这样的人让我不喜欢stackoverflow.
完全误导基准.在C++版本中,您只需保留部分内存(然后惊叹该操作如何执行微秒).在C#版本中,您创建了5000个ARRAYS(在内存中实例化对象).C++比C#更快......但是差距远不及40%......现在它的范围更加<10%.你的例子说明程序员应该坚持自己选择的语言(从你的个人资料中可以看出你是职业C++程序员).在C#中你可以做2D数组`int [,]`......跟随例子.
@MarkusKnappenJohansson我度过了糟糕的一天;),我也只是一个人,删除了我的downvote,但我的观点仍然适用.哦,请不要因为有一些"愚蠢"的人:)而不喜欢.祝你好一个.
据我所知,C++示例中的代码实际上只是提前分配内存.PROPER C#实现只需编写'List arrs = new List (ROWS*COLS)',它分配以一维格式索引二维数组所需的内存(例如,你在C++中所做的).绝对没有理由分配二维数组并手动压平它 - 预测试中的大量迭代是导致性能不佳的原因.我想C#中的开销仍然更多,但不是很多.

5> Nemanja Trif..：

根据我的经验(我用两种语言都做了很多工作),C#与C++相比的主要问题是高内存消耗,我还没有找到一种控制它的好方法.内存消耗最终会减慢.NET软件的速度.

另一个因素是JIT编译器不能承受太多时间来进行高级优化,因为它在运行时运行,如果花费太多时间,最终用户会注意到它.另一方面,C++编译器始终需要在编译时进行优化.这个因素远没有内存消耗那么重要,恕我直言.

@IngeHenriksen处理它只能确保调用Dispose方法.处置永远不会释放垃圾收集的内存.Dispose方法仅用于清理非托管资源(如文件句柄),与内存管理无关.
@IngeHenriksen:我很清楚Dispose模式,但它根本没有帮助管理内存.
在一个工作项目中,我们不得不挖掘大量的数据,包括同时在内存中保存许多GB并对所有数据执行昂贵的计算 - 这需要精确控制所有分配,C++几乎是唯一的选择.+1代表C++.另一方面,这只是一个项目,我们花了大部分时间编写与慢速模拟器交互的系统,调试可能是一场噩梦,所以我希望我们可以使用程序员时间优化语言来完成其他所有项目.东西.
@ user3800527:即使添加RAM始终可行(并且它不是 - 想象微软向每个MS Office用户添加RAM)也无法解决问题.内存是分层的,C#程序比C++程序有更多的缓存未命中.

6> Konrad Rudol..：

在编译时可以预先确定多态决策的情况下,C++仍然具有优势(并将在未来几年内发挥作用)的一种特殊情况发生.

通常,封装和延迟决策是一件好事,因为它使代码更加动态,更容易适应不断变化的需求并更容易用作框架.这就是为什么C#中的面向对象编程非常有效并且可以在术语"泛化"下概括的原因.不幸的是,这种特殊的泛化在运行时需要付出代价.

通常,这个成本是非实质性的,但是有些应用程序中虚拟方法调用和对象创建的开销会产生影响(特别是因为虚方法会阻止其他优化,例如方法调用内联).这就是C++具有巨大优势的地方,因为您可以使用模板来实现不同类型的泛化,这种泛化对运行时没有影响,但不一定比OOP更少多态.事实上,构成OOP的所有机制都可以仅使用模板技术和编译时解析来建模.

在这种情况下(并且不可否认,它们通常仅限于特殊问题域),C++赢得了C#和类似的语言.

@crtracy:您在没有高性能计算应用程序的情况下下注.考虑天气预报,生物信息学和数值模拟.C++在这些领域的性能领先优势将不会缩小,因为没有其他代码可以在相同的高抽象级别上实现相当的性能.
实际上,Java VM(可能还有.NET)竭尽全力避免动态调度.基本上,如果有办法避免多态,你可以非常肯定你的VM会这样做.
@Jon苹果和橘子.您的具体主张是"在元编程的上下文中C#比C++快几个数量级",而不是"使用预编译的代码比解释代码快几个数量级".虽然我们在这方面,你声称运行时代码生成比编译时代码生成"更通用"也是明显错误的 - 它们都有优点和缺点.编译时代码生成使用类型系统来提供静态类型安全性 - 运行时代码生成不能这样做(它*可以*提供强类型安全性,但不提供*静态*类型安全性).
@ user3800527我认为你错过了这个答案的全部要点.当然,您可以通过打破封装并降低到低级结构来解决这个问题 - 您可以用(大多数)任何语言编写汇编.使C++(几乎)独一无二,并且非常适合高性能编程的是,您可以构建*高级*抽象,*no*运行时成本.因此,您不需要在C++中编写类似汇编的代码来获得高级性能:编写良好的`sort(arr,generic_comparer)`将与C++中的手写循环一样高效.它永远不会在C#中.
+1我总是很难向我的C#同事解释这一点,他们知道很少的C++,使他们能够理解其重要性.你已经很好地解释了它.
@JonHarrop顺便说一句,为了避免误解,我承认C#元编程功能*更强大*因为你可以在运行时*使用它*.我对你的"数量级更快"的声明提出质疑,这是错误的.
@Luaan不,这真的不可能.C++可以做什么,其他语言不能*即使外部函数没有内联*,内部函数也会.例如,想象一个接受`comparator`参数的`Sort`方法.在C++中,即使`Sort`不是,也可以内联这个`comparator`.在您列出的语言中,这基本上是*不可能的,这是设计限制,而不是可能在将来消失的技术限制.
@Luaan你混淆了什么是合法的,技术上可能的.C++只能执行此操作,因为它为每个模板类型生成不同的外部函数(有关详细信息,请参阅http://stackoverflow.com/a/13722515/1968):函数本身标记为(静态)类型.在.NET中,外部函数没有标记不同的类型,既不是静态的也不是动态的.要根据不同的参数为它生成单独的代码,优化者必须解决一个问题,据我所知,[intractable](https://en.wikipedia.org/wiki/Computational_complexity_theory#Intractability).
我知道虚拟机的能力.然而,这更进一步.重点是模板C++代码*do*使用"动态"调度,或者说是类似的东西.
@Jon然后在C ++中使用更好的正则表达式引擎（可能没有一个；但这不是基本限制-但实际上有*这样的引擎，例如Boost.Xpressive）。您的第二个说法很可笑。
@ user3800527没有人对此表示异议，但是我不知道.net的单个实现可以使用它内联，例如，在排序算法循环内内调用`IComparer`。C ++可以做到这一点。
@Luaan并且，为了澄清一下：我并不是说绝对不可能执行此优化（这显然是愚蠢的），而是不可能在合理的时间内执行此操作（=关于表达式复杂度）–在评估是否可以在运行时执行给定的优化时，这很重要。

7> ConcernedOfT..：

C++(或者C就此而言)为您提供了对数据结构的细粒度控制.如果你想捏捏你有这个选择.使用Java/.NET库的内部数据结构的大型托管Java或.NET应用程序(OWB,Visual Studio 2005)随身携带.我已经看到OWB设计师会话使用超过400 MB的RAM和BIDS进行立方体或ETL设计也可以进入100的MB.

在可预测的工作负载(例如多次重复进程的基准测试)上,JIT可以为您提供经过充分优化的代码,使其没有实际差异.

IMO在大型应用程序上的区别不在于JIT与代码本身正在使用的数据结构.如果应用程序占用大量内存,则缓存使用效率会降低.现代CPU上的高速缓存未命中非常昂贵.在C或C++真正获胜的地方,您可以优化数据结构的使用,以便与CPU缓存很好地协同工作.



8> QBziZ..：

对于图形,标准C#Graphics类比通过C/C++访问的GDI慢.我知道这与语言本身无关,更多的是与整个.NET平台有关,但Graphics是作为GDI替代品提供给开发人员的,而且它的性能非常糟糕我甚至不敢做图形用它.

我们有一个简单的基准测试,用于查看图形库的速度,并且只是在窗口中绘制随机线.C++/GDI仍然很容易使用10000行,而C#/ Graphics难以实时执行1000行.

这不是我们想要做的,自己将单独的像素放在帧缓冲区中.如果你必须自己实现一切,那么有一个API /平台可以编写代码吗？对我来说,这是一个非争论.我们永远不需要在GDI中的帧缓冲区中放置单独的像素来绘制线条,我们也不打算在.NET中执行此操作.在我看来,我们确实使用了一个现实的指标,而.NET却变得很慢.
我对你的回答很感兴趣.你是否用不安全的代码和lockbits测试了相同的基准测试,并自己绘制随机线？现在**将是一个有趣的事情要看.
@Pedery nope我没有.只是以最基本的方式使用GDI和.NET.Graphics.你自己画"随机线"是什么意思？

9> 小智..：

垃圾收集是Java#不能用于实时系统的主要原因.

    GC何时会发生？

    这需要多长时间？

这是不确定的.

这是一个无意义的论点,Windows(和Linux)不是实时操作系统.您的C++代码也可以随时换出多个18毫秒的插槽.
我不是一个巨大的Java粉丝,但没有任何东西说Java不能使用实时友好的GC.
如果你想看,有很多实时的GC实现.(GC是一个*溢出*研究论文的领域)
@HenkHolterman是的，但是您始终可以在程序集中编写一个引导程序，将其绑定到应用程序的内核引导程序中，然后直接针对硬件（在RT btw中）执行C ++应用程序。您无法在C＃中做到这一点，我所做的任何努力都只能模仿C＃中的预编译程序集并使用大量的C代码，这使得使用C＃毫无意义。读所有这些真是有趣，因为如果没有.NET框架，C＃实际上是无用的。

10> ILoveFortran..：

我们不得不确定C#在性能上是否与C++相当,我为此编写了一些测试程序(对于这两种语言使用Visual Studio 2005).事实证明,没有垃圾收集,只考虑语言(而不是框架),C#与C++的性能基本相同.C#中的内存分配比C++中更快,当数据大小超出缓存行边界时,C#在确定性方面略有优势.然而,所有这些最终都要付出代价,并且由于垃圾收集,C#的非确定性性能命中形式会产生巨大的成本.

@ zackery.fix .NET在堆分配方面有一个有趣的优势,因为它只需要移动一个指针来分配一个新对象.由于压缩垃圾收集器,这是可行的.当然你可以在C++中做同样的事情,但C++不这样做.有趣的是你如何使用相同的参数来说"C#可以但不是,所以它是垃圾"和"C++没有,但它可以,所以它很棒":)

11> Dark Shikari..：

像往常一样,这取决于应用程序.有些情况下C#的速度可能会慢得多,而其他情况下C++的速度要慢5到10倍,特别是在操作可以轻松进行SIMD的情况下.



12> Kramii Reins..：

我知道这不是你所要求的,但C#通常比C++ 写得更快,这在商业环境中是一个很大的好处.

我会说大多数时候它更快:)

13> 小智..：

>据我所知......

您的困难似乎在于决定您所听到的内容是否可信,并且当您尝试评估此网站上的回复时,将会重复这一困难.

你怎么决定人们在这里说的话比你原来听到的更可靠或更不可信？

一种方法是要求证据.

当有人声称"有些领域C#证明比C++更快"时,问他们为什么这么说,请他们告诉你测量结果,让他们向你展示程序.有时他们会犯错误.有时你会发现他们只是表达了一种意见,而不是分享他们可以证明是真实的东西.

通常情况下,信息和意见会混淆在人们所声称的内容中,你必须尝试找出哪个是哪个.例如,来自本论坛的回复:

"请参考http://shootout.alioth.debian.org/ 上的基准测试,因为这些基本上是测试算术代码,很可能与你的代码完全不同."

问问自己,你是否真的理解"这些主要测试算术代码"的意思,然后问问自己作者是否真的向你证明他的说法是正确的.

"这是一个相当无用的测试,因为它实际上取决于各个程序的优化程度;我已经设法将其中一些程序加速了4-6倍或更多,明确表示未经优化的程序之间的比较是相当的愚蠢."

问问自己,作者是否真的告诉过你他已经设法"将其中一些加速了4-6倍或更多" - 这是一个很容易的声明!



14> Special Sauc..：

C/C++可以在程序中执行得更好,在这些程序中有大型数组或重型循环/迭代数组(任何大小).这就是图形在C/C++中通常要快得多的原因,因为重型阵列操作几乎是所有图形操作的基础.由于所有的安全检查,.NET在数组索引操作中的速度非常慢,对于多维数组尤其如此(是的,矩形C#数组甚至比锯齿状C#数组慢).

如果直接使用指针并避免使用Boost std::vector和其他高级容器,以及inline可能的每个小功能,C/C++的奖励最为明显.尽可能使用旧式数组.是的,您将需要更多代码行来完成与Java或C#相同的操作,因为您避免使用高级容器.如果你需要一个动态大小的数组,你只需要记住将你new T[]与相应的delete[]语句(或使用std::unique_ptr)配对- 额外速度的价格是你必须更仔细地编码.但作为交换,你可以摆脱托管内存/垃圾收集器的开销,这可能很容易占Java和.NET中大量面向对象程序执行时间的20%或更多,以及那些大量托管内存数组索引成本.在某些特定情况下,C++应用程序也可以从一些漂亮的编译器开关中受益.

我是C,C++,Java和C#的专家程序员.我最近有机会在后3种语言中实现完全相同的算法程序.该程序有很多数学和多维数组操作.我用所有3种语言对其进行了大量优化.结果是我通常在不太严格的比较中看到的典型结果:Java比C#快大约1.3倍(大多数JVM比CLR更优化),而C++原始指针版本的速度比C#快大约2.1倍.请注意,C#程序仅使用安全代码 - 我认为您在使用unsafe关键字之前也可以使用C++对其进行编码.

为了避免有人认为我有反对C#的东西,我最后会说C#可能是我最喜欢的语言.它是迄今为止我遇到的最合乎逻辑,最直观,最快速的开发语言.我在C#中做了所有的原型设计.与Java相比,C#语言具有许多小的,微妙的优势(是的,我知道微软有机会通过较晚进入游戏并且可以复制Java来修复Java的许多缺点).向Java的Calendar班级敬酒吗？如果微软花费了大量精力来优化CLR和.NET JITter,那么C#可以认真接管.我真的很惊讶他们还没有 - 他们在C#语言中做了很多事情,为什么不跟着重击编译器优化呢？也许如果我们都乞求.

_"你只需要记住将你的`new T []`与相应的`delete []`"对 - " - 不,你不需要.有`std :: unique_ptr`可以帮到你.

15> Dmitri Neste..：

对于"令人尴尬的并行"问题,当在C++上使用英特尔TBB和OpenMP时,我发现与使用C#和TPL完成的类似(纯数学)问题相比,性能提升了大约10倍.SIMD是C#无法竞争的一个领域,但我也觉得TPL有相当大的开销.

也就是说,我只使用C++进行性能关键任务,我知道我将能够多线程并快速获得结果.对于其他一切,C#(偶尔也是F#)就好了.



16> Florian Doyo..：

.NET语言可以像C++代码一样快,甚至更快,但是C++代码将具有更恒定的吞吐量,因为.NET运行时必须为GC暂停,即使它对其暂停非常聪明.

因此,如果您的某些代码必须始终如一地快速运行而没有任何暂停,那么即使您对运行时GC非常小心,.NET也会在某些时候引入延迟.

-1:这实际上是一个神话.首先,惯用C++的延迟实际上非常糟糕,而且往往比.NET差得多,因为当大型数据结构超出范围时RAII会导致雪崩析构,而现代GC是渐进式的,而.NET甚至是并发的.其次,您实际上可以通过不分配来完全删除.NET上的GC暂停.
这是非常正确的,直到.net 4才使GC成为增量式的.我们有一个大型的C#应用​​程序,一次暂停GC一秒钟.对于性能关键应用程序,这是一个杀手.
倾向于推动硬件的程序倾向于使用C++是有原因的.您需要时可以进行更精细的控制.在推送系统时,性能才是关键,否则使用C#或Java可以节省时间.
如果您无法管理缓存行为,则无法击败优化的c ++代码.从L1到主存储器的高速缓存未命中可能会使您的操作减慢100次.
如果这样做,则必须放弃使用BCL,因为大多数方法都会创建瞬态对象.

17> 小智..：

没有真正明确的答案,这是一个非常模糊的问题.

例如; 我宁愿玩用C++创建的3D游戏而不是C#,因为性能肯定要好得多.(而且我知道XNA等等,但它并没有接近真实的东西).

另一方面,如前所述; 你应该用一种语言进行开发,让你快速做你想做的事,然后在必要时进行优化.

垃圾收集器是用C#制作游戏的一个巨大责任,因为它可以随时启动,导致重大停顿.显式内存管理最终会使游戏开发变得更容易.
你能说出几个例子吗？用C#写的游戏你发现的很慢
大多数现代游戏都是GPU限制的.对于这样的游戏,如果逻辑(在CPU上执行)慢10%并不重要,它们仍受GPU而不是CPU的限制.垃圾收集器是一个真正的问题,如果内存分配调得不好,会导致随机短暂冻结.
@postfuturist:PC上的情况并非如此; 垃圾收集器做得很好,我从来没有遇到任何问题.然而,在XBox 360和Zune/Windows-7-Phone上,垃圾收集器并不像PC上那样聪明!我从来没有写过,但是[有的人](http://gamedev.stackexchange.com/questions/7/what-are-typical-pitfalls-when-writing-games-with-a-managed-language -like-c/210#210)告诉我垃圾收集器是一个*巨大的*问题.
推荐阅读
devbox
放ch养奶牛
这个屌丝很懒，什么也没留下！
关注作者
Tags | 热门标签
RankList | 热门文章
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有