C++ 比 C# 快多少?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/138361/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-03 15:07:58  来源:igfitidea点击:

How much faster is C++ than C#?

提问by Trap

Or is it now the other way around?

还是现在相反?

From what I've heard there are some areas in which C# proves to be faster than C++, but I've never had the guts to test it by myself.

据我所知,在某些领域 C# 被证明比 C++ 快,但我从来没有勇气亲自测试它。

Thought any of you could explain these differences in detail or point me to the right place for information on this.

认为你们中的任何人都可以详细解释这些差异或将我指向正确的地方以获取有关此信息的信息。

采纳答案by Martin Probst

There is no strict reason why a bytecode based language like C# or Java that has a JIT cannot be as fast as C++ code. However C++ code used to be significantly faster for a long time, and also today still is in many cases. This is mainly due to the more advanced JIT optimizations being complicated to implement, and the really cool ones are only arriving just now.

没有严格的理由说明为什么像 C# 或 Java 这样具有 JIT 的基于字节码的语言不能像 C++ 代码一样快。然而,C++ 代码在很长一段时间内都明显更快,今天在许多情况下仍然如此。这主要是因为更高级的 JIT 优化实现起来很复杂,而真正酷的优化才刚刚到来。

So C++ is faster, in many cases. But this is only part of the answer. The cases where C++ is actually faster, are highly optimized programs, where expert programmers thoroughly optimized the hell out of the code. This is not only very time consuming (and thus expensive), but also commonly leads to errors due to over-optimizations.

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

On the other hand, code in interpreted languages gets faster in later versions of the runtime (.NET CLR or Java VM), without you doing anything. And there are a lot of useful optimizations JIT compilers can do that are simply impossible in languages with pointers. Also, some argue that garbage collection should generally be as fast or faster as manual memory management, and in many cases it is. You can generally implement and achieve all of this in C++ or C, but it's going to be much more complicated and error prone.

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

As Donald Knuth said, "premature optimization is the root of all evil". If you really know for sure that your application will mostly consist of very performance critical arithmetic, and that it will be the bottleneck, and it's certainly going to be faster in C++, and you're sure that C++ won't conflict with your other requirements, go for C++. In any other case, concentrate on first implementing your application correctly in whatever language suits you best, then find performance bottlenecks if it runs too slow, and then think about how to optimize the code. In the worst case, you might need to call out to C code through a foreign function interface, so you'll still have the ability to write critical parts in lower level language.

正如 Donald Knuth 所说,“过早的优化是万恶之源”。如果您真的确定您的应用程序将主要由非常关键的算法组成,并且它将成为瓶颈,并且它肯定会在 C++ 中更快,并且您确定 C++ 不会与您的其他算法发生冲突要求,去 C++。在任何其他情况下,首先专注于以最适合您的语言正确实现您的应用程序,然后在运行速度太慢时找到性能瓶颈,然后考虑如何优化代码。在最坏的情况下,您可能需要通过外部函数接口调用 C 代码,因此您仍然可以用低级语言编写关键部分。

Keep in mind that it's relatively easy to optimize a correct program, but much harder to correct an optimized program.

请记住,优化正确的程序相对容易,但更正优化的程序要困难得多。

Giving actual percentages of speed advantages is impossible, it largely depends on your code. In many cases, the programming language implementation isn't even the bottleneck. Take the benchmarks at http://benchmarksgame.alioth.debian.org/with a great deal of scepticism, as these largely test arithmetic code, which is most likely not similar to your code at all.

给出速度优势的实际百分比是不可能的,这在很大程度上取决于您的代码。在许多情况下,编程语言实现甚至不是瓶颈。对http://benchmarksgame.alioth.debian.org/上的基准测试持怀疑态度,因为它们主要测试算术代码,这很可能与您的代码根本不相似。

回答by Konrad Rudolph

It's five oranges faster. Or rather: there can be no (correct) blanket answer. C++ is a statically compiled language (but then, there's profile guided optimization, too), C# runs aided by a JIT compiler. There are so many differences that questions like “how much faster” cannot be answered, not even by giving orders of magnitude.

快了五个橙子。或者更确切地说:不可能有(正确的)一揽子答案。C++ 是一种静态编译语言(但是,也有配置文件引导的优化),C# 在 JIT 编译器的帮助下运行。差异如此之多,以至于无法回答诸如“多快多少”之类的问题,甚至无法给出数量级。

回答by Dark Shikari

As usual, it depends on the application. There are cases where C# is probably negligibly slower, and other cases where C++ is 5 or 10 times faster, especially in cases where operations can be easily SIMD'd.

像往常一样,这取决于应用程序。在某些情况下,C# 可能会慢到可以忽略不计,而在其他情况下,C++ 会快 5 或 10 倍,尤其是在操作可以轻松进行 SIMD 的情况下。

回答by mattlant

C# may not be faster, but it makes YOU/ME faster. That's the most important measure for what I do. :)

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

回答by Konrad Rudolph

One particular scenario where C++ still has the upper hand (and will, for years to come) occurs when polymorphic decisions can be predetermined at compile time.

当可以在编译时预先确定多态决策时,C++ 仍然占上风(并且将在未来几年内)发生的一种特殊情况。

Generally, encapsulation and deferred decision-making is a good thing because it makes the code more dynamic, easier to adapt to changing requirements and easier to use as a framework. This is why object oriented programming in C# is very productive and it can be generalized under the term “generalization”. Unfortunately, this particular kind of generalization comes at a cost at run-time.

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

Usually, this cost is non-substantial but there are applications where the overhead of virtual method calls and object creation can make a difference (especially since virtual methods prevent other optimizations such as method call inlining). This is where C++ has a huge advantage because you can use templates to achieve a different kind of generalization which has noimpact on runtime but isn't necessarily any less polymorphic than OOP. In fact, all of the mechanisms that constitute OOP can be modelled using only template techniques and compile-time resolution.

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

In such cases (and admittedly, they're often restricted to special problem domains), C++ wins against C# and comparable languages.

在这种情况下(不可否认,它们通常仅限于特殊的问题领域),C++ 战胜了 C# 和类似的语言。

回答by ConcernedOfTunbridgeWells

C++ (or C for that matter) gives you fine-grained control over your data structures. If you want to bit-twiddle you have that option. Large managed Java or .NET apps (OWB, Visual Studio 2005) that use the internal data structures of the Java/.NET libraries carry the baggage with them. I've seen OWB designer sessions using over 400 MB of RAM and BIDS for cube or ETLdesign getting into the 100's of MB as well.

C++(或就此而言的 C)使您可以对数据结构进行细粒度控制。如果你想有点麻烦,你有这个选择。使用 Java/.NET 库的内部数据结构的大型托管 Java 或 .NET 应用程序(OWB、Visual Studio 2005)随身携带。我见过使用超过 400 MB 的 RAM 和 BIDS 进行多维数据集或ETL设计的OWB 设计师会议也进入了 100 MB。

On a predictable workload (such as most benchmarks that repeat a process many times) a JIT can get you code that is optimised well enough that there is no practical difference.

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

IMO on large applications the difference is not so much the JIT as the data structures that the code itself is using. Where an application is memory-heavy you will get less efficient cache usage. Cache misses on modern CPUs are quite expensive. Where C or C++ really win is where you can optimise your usage of data structures to play nicely with the CPU cache.

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

回答by David The Man

It's an extremely vague question without real definitive answers.

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

For example; I'd rather play 3D-games that are created in C++ than in C#, because the performance is certainly a lot better. (And I know XNA, etc., but it comes no way near the real thing).

例如; 我宁愿玩用 C++ 创建的 3D 游戏而不是用 C#,因为性能肯定要好得多。(我知道 XNA 等,但它与真实的东西相差甚远)。

On the other hand, as previously mentioned; you should develop in a language that lets you do what you want quickly, and then if necessary optimize.

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

回答by Nemanja Trifunovic

In my experience (and I have worked a lot with both languages), the main problem with C# compared to C++ is high memory consumption, and I have not found a good way to control it. It was the memory consumption that would eventually slow down .NET software.

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

Another factor is that JIT compiler cannot afford too much time to do advanced optimizations, because it runs at runtime, and the end user would notice it if it takes too much time. On the other hand, a C++ compiler has all the time it needs to do optimizations at compile time. This factor is much less significant than memory consumption, IMHO.

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

回答by Kramii

I know it isn't what you were asking, but C# is often quicker to writethan C++, which is a big bonus in a commercial setting.

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

回答by bgee

I suppose there are applications written in C# running fast, as well as there are more C++ written apps running fast (well C++ just older... and take UNIX too...)
- the question indeed is - what is that thing, users and developers are complaining about ...
Well, IMHO, in case of C# we have very comfort UI, very nice hierarchy of libraries, and whole interface system of CLI. In case of C++ we have templates, ATL, COM, MFC and whole shebang of alreadyc written and running code like OpenGL, DirectX and so on... Developers complains of indeterminably risen GC calls in case of C# (means program runs fast, and in one second - bang! it's stuck).
To write code in C# very simple and fast (not to forget that also increase chance of errors. In case of C++, developers complains of memory leaks, - means crushes, calls between DLLs, as well as of "DLL hell" - problem with support and replacement libraries by newer ones...
I think more skill you'll have in the programming language, the more quality (and speed) will characterize your software.

我想有一些用 C# 编写的应用程序运行得很快,还有更多的 C++ 编写的应用程序运行得很快(C++ 只是更老了......而且也使用 UNIX......)
- 问题确实是 - 那是什么东西,用户开发人员抱怨......
好吧,恕我直言,在 C# 的情况下,我们有非常舒适的 UI、非常好的库层次结构和 CLI 的整个界面系统。在 C++ 的情况下,我们有模板、ATL、COM、MFC 和已经编写和运行的代码(如 OpenGL、DirectX 等)的整个shebang……开发人员抱怨在 C# 的情况下无法确定地增加 GC 调用(意味着程序运行速度快,并且在一秒钟内 - 砰!它被卡住了)。
在 C# 中编写代码非常简单和快速(不要忘记这也会增加出错的机会。在 C++ 的情况下,开发人员抱怨内存泄漏,-意味着崩溃,DLL 之间的调用,以及“DLL 地狱”-问题支持和替换新的库...
我认为您在编程语言方面拥有的技能越多,您的软件的质量(和速度)就越高。