还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
当前回答
c#和c++在性能方面有一些主要的区别:
c#是基于GC /堆的。分配和GC本身是内存访问的非局部性开销 多年来,c++优化器已经变得非常好。JIT编译器无法达到相同的级别,因为它们只有有限的编译时间,并且看不到全局作用域
除此之外,程序员的能力也很重要。我见过一些糟糕的c++代码,其中的类通过值作为参数传递。在c++中,如果你不知道自己在做什么,实际上会让性能变差。
其他回答
我想这么说:编写更快代码的程序员,是那些更了解当前机器运行速度的人,顺便说一句,他们也是那些使用适当工具的人,这些工具允许精确的低级和确定性优化技术。由于这些原因,这些人使用C/ c++而不是c#。我甚至认为这是事实。
如果我没记错的话,c#模板是在运行时确定的。这肯定比c++的编译时模板慢。
当你考虑到很多人提到的所有其他编译时优化,以及安全性的缺失,确实意味着更高的速度……
我想说,就原始速度和最小内存消耗而言,c++是显而易见的选择。但这也转化为更多的时间来开发代码,并确保您不会泄漏内存或导致任何空指针异常。
结论:
c#:更快的开发,更慢的运行 c++:开发慢,运行快。
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.
In theory, for long running server-type application, a JIT-compiled language can become much faster than a natively compiled counterpart. Since the JIT compiled language is generally first compiled to a fairly low-level intermediate language, you can do a lot of the high-level optimizations right at compile time anyway. The big advantage comes in that the JIT can continue to recompile sections of code on the fly as it gets more and more data on how the application is being used. It can arrange the most common code-paths to allow branch prediction to succeed as often as possible. It can re-arrange separate code blocks that are often called together to keep them both in the cache. It can spend more effort optimizing inner loops.
我怀疑。net或任何jre都能做到这一点,但早在我上大学的时候就有人在研究这一点,所以认为这类东西很快就会在现实世界中找到自己的方式也不是不合理的。
We have had to determine if C# was comparable to C++ in performance and I wrote some test programs for that (using Visual Studio 2005 for both languages). It turned out that without garbage collection and only considering the language (not the framework) C# has basically the same performance as C++. Memory allocation is way faster in C# than in C++ and C# has a slight edge in determinism when data sizes are increased beyond cache line boundaries. However, all of this had eventually to be paid for and there is a huge cost in the form of non-deterministic performance hits for C# due to garbage collection.