还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
当前回答
我发现2020年4月读过:https://www.quora.com/Why-is-C-so-slow-compared-to-Python,作者是一位拥有15年以上软件开发经验的现实世界的程序员。
它指出,c#通常较慢,因为它被编译为公共中间语言(CIL),而不是像c++那样的机器代码。然后,CIL通过公共语言运行库(CLR)输出机器代码。但是,如果您继续执行c#,它将获取机器代码的输出并缓存它,以便为下次执行保存机器代码。总而言之,如果多次执行,c#会更快,因为它是多次执行后的机器代码。
也有评论说,一个优秀的c++程序员可以做一些耗时的优化,但最终会被优化。
其他回答
对于图形来说,标准的c#图形类比通过C/ c++访问的GDI慢得多。 我知道这与语言本身无关,更多的是与整个。net平台有关,但是图形是作为GDI替代品提供给开发人员的,它的性能非常糟糕,我甚至不敢用它来处理图形。
我们有一个简单的基准来查看图形库的速度,那就是在窗口中随机绘制线条。c++ /GDI在处理10000行代码时仍然很灵活,而c# /Graphics在处理1000行代码时却很难做到。
c++(或C)为您提供了对数据结构的细粒度控制。如果你想玩,你有这个选择。大型托管Java或。net应用程序(OWB, Visual Studio 2005),它们使用Java/。NET库自带包袱。我曾见过OWB设计会话使用超过400 MB的RAM,立方体或ETL设计的bid也达到100 MB。
在可预测的工作负载上(例如重复一个过程多次的大多数基准测试),JIT可以为您提供优化得足够好的代码,没有实际差别。
在大型应用程序上,差异与其说是JIT,不如说是代码本身使用的数据结构。当应用程序的内存很重时,您将获得较低的缓存使用效率。在现代cpu上,缓存丢失是非常昂贵的。C或c++的真正优势在于,您可以优化数据结构的使用,从而更好地使用CPU缓存。
如果我没记错的话,c#模板是在运行时确定的。这肯定比c++的编译时模板慢。
当你考虑到很多人提到的所有其他编译时优化,以及安全性的缺失,确实意味着更高的速度……
我想说,就原始速度和最小内存消耗而言,c++是显而易见的选择。但这也转化为更多的时间来开发代码,并确保您不会泄漏内存或导致任何空指针异常。
结论:
c#:更快的开发,更慢的运行 c++:开发慢,运行快。
在一个特殊的场景中,c++仍然占据上风(并且将在未来几年占据上风),即可以在编译时预先确定多态决策。
通常,封装和延迟决策是一件好事,因为它使代码更加动态,更容易适应不断变化的需求,并且更容易作为框架使用。这就是为什么在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 no impact 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++胜过c#和类似的语言。
通常,这取决于应用程序。在某些情况下,c#可能慢得可以忽略不计,而在其他情况下,c++要快5到10倍,特别是在操作可以轻松SIMD的情况下。