C++比C#快多少？

Question

C++比C#快多少？

Tra*_*rap 230 c# c++ performance benchmarking

或者它现在反过来了？

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

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

Answer 1

没有严格的理由说明基于字节码的语言(如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/上的基准测试,因为这些基本上是测试算术代码,很可能与您的代码完全不同.

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

Answer 2

mat*_*ant 189

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

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

Answer 3

Kon*_*lph 81

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

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

Answer 4

U00*_*07D 80

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

实际上有很多原因导致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);
}

Run Code Online (Sandbox Code Playgroud)

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

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

#include <iostream>
#include <vector>

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

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

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

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(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<double>(r * c);
        }
    }

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

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

Run Code Online (Sandbox Code Playgroud)

运行时间(释放):初始值: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代码在某种程度上比原生代码更快 - 事实并非如此,基准测试可能会误导新人. (16认同)
支持有意义的基准;-) (9认同)
@Quonux你为什么要这样写？像你这样的人让我不喜欢stackoverflow. (9认同)
完全误导基准.在C++版本中,您只需保留部分内存(然后惊叹该操作如何执行微秒).在C#版本中,您创建了5000个ARRAYS(在内存中实例化对象).C++比C#更快......但是差距远不及40%......现在它的范围更加<10%.你的例子说明程序员应该坚持自己选择的语言(从你的个人资料中可以看出你是职业C++程序员).在C#中你可以做2D数组`int [,]`......跟随例子. (9认同)
@MarkusKnappenJohansson我度过了糟糕的一天;),我也只是一个人,删除了我的downvote,但我的观点仍然适用.哦,请不要因为有一些"愚蠢"的人:)而不喜欢.祝你好一个. (5认同)
因此，我在我的机器上重做了 C# 示例以使用更接近基准测试中使用的 `double[,]`。它仍然不是完美的比较，因为 C# 中的几乎任何东西都是在内存中初始化的对象（并且那里有开销）。结果：初始化耗时 3 毫秒，执行耗时 95 毫秒。所以我现在可以声明 C# 比 C++ 快 40%。这显然不是真的。也许我的机器比@U007D 快。也许我忘记设置发布模式（然后我的代码需要 >300 毫秒才能执行）。结论：编译代码的速度是相等的。您编写代码的程度是一个更大的因素。 (3认同)
相当肯定你在 C++ 示例中所做的事情是非法的（几乎肯定可以工作，但非法）。您调用“arr.reserve(ROWS * COLS);”，这使得可以“push_back”“ROWS * COLS”次而不触发重新分配。但是，您可以手动分配逐渐增加的“arr”索引，而不是重复的“push_back”。这在实践中是有效的，因为内存就在那里，并且“operator[]”没有进行边界检查，但它是未定义的行为（“向量”的大小仍然是“0”，并且您正在访问一个不存在的元素）。 (3认同)
据我所知,C++示例中的代码实际上只是提前分配内存.PROPER C#实现只需编写'List <double> arrs = new List <double>(ROWS*COLS)',它分配以一维格式索引二维数组所需的内存(例如,你在C++中所做的).绝对没有理由分配二维数组并手动压平它 - 预测试中的大量迭代是导致性能不佳的原因.我想C#中的开销仍然更多,但不是很多. (2认同)
正如其他人所说，c# 实现非常低效。另外，时间是通过减去 DateTime 对象来测量的，这不是正确的用法（精度不够，比秒表重）。这篇文章只是证明人们应该更喜欢他们熟悉的语言而不是在线基准。 (2认同)

Answer 5

Nem*_*vic 61

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

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

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

Answer 6

Kon*_*lph 33

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

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

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

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

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

Answer 7

Con*_*lls 19

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缓存很好地协同工作.

Answer 8

QBz*_*ziZ 19

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

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

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

Answer 9

小智 13

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

GC何时会发生？
这需要多长时间？

这是不确定的.

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

Answer 10

ILo*_*ran 11

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

@ zackery.fix .NET在堆分配方面有一个有趣的优势,因为它只需要移动一个指针来分配一个新对象.由于压缩垃圾收集器,这是可行的.当然你可以在C++中做同样的事情,但C++不这样做.有趣的是你如何使用相同的参数来说"C#可以但不是,所以它是垃圾"和"C++没有,但它可以,所以它很棒":) (5认同)
在 C++ 中，您可以选择使用不同的分配方法，因此根据 C# 中的内存分配方式（AOT？），可以在 C++ 中以相同的方式完成（但速度更快）。 (2认同)

Answer 11

Dar*_*ari 9

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

Answer 12

Kra*_*ica 9

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

我会说大多数时候它更快:) (2认同)

Answer 13

小智 7

>据我所知......

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

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

一种方法是要求证据.

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

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

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

问问自己,你是否真的理解"这些主要测试算术代码"的意思,然后问问自己作者是否真的向你证明他的说法是正确的.
"这是一个相当无用的测试,因为它实际上取决于各个程序的优化程度;我已经设法将其中一些程序加速了4-6倍或更多,明确表示未经优化的程序之间的比较是相当的愚蠢."

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

Answer 14

Spe*_*uce 7

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`可以帮到你. (2认同)

Answer 15

Dmi*_*ruk 6

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

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

Answer 16

Flo*_*yon 6

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

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

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

Answer 17

Dav*_*Man 5

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

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

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

垃圾收集器是用C#制作游戏的一个巨大责任,因为它可以随时启动,导致重大停顿.显式内存管理最终会使游戏开发变得更容易. (9认同)
你能说出几个例子吗？用C#写的游戏你发现的很慢 (4认同)
大多数现代游戏都是GPU限制的.对于这样的游戏,如果逻辑(在CPU上执行)慢10%并不重要,它们仍受GPU而不是CPU的限制.垃圾收集器是一个真正的问题,如果内存分配调得不好,会导致随机短暂冻结. (3认同)
@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)告诉我垃圾收集器是一个*巨大的*问题. (2认同)

归档时间：	17 年前
查看次数：	145804 次
最近记录：	6 年，4 月前