神马文学网C# vs C/C Performance - CodeProject
来源：百度文库 编辑：神马文学网 时间：2024/04/27 16:45:20
Introduction
Well, this is my first postin this technology series. In fact, thetitle of this post, forced me to start of a technology focused blog.Well said about all these, let's now jump into the issue.
Therehas been a lot of heated discussion on different forums, newsgroups,and various other threads about the above topic. Now why should Idiscuss about the same again here?
Well, though there are manydiscussion groups that claim C++ to be faster and efficient, a smallgroup of people still claim C# to be more efficient.
How the hell cana language that is not compiled to a native code be faster that a C++binary?
Thoughthe above statement is perfectly valid from the point of C++programmers, I would like to highlight a few points that could statewhy some (not all) C# programs are *really faster* than it's equivalentC++ programs.
Point 1:C# is compiled twice. Once while the program is written and second whenthe program is executed at the user's site. The first compilation isdone by your C# builder and the second by the .NET Framework on theuser's machine. The reason why C# compiled applications could be fasteris that, during the second compilation, the compiler knows the actualrun-time environment and processor type and could generate instructionsthat targets a specific processor. Classical C++ compilers generatenative code that is usually the Lowest Common Denominator of all theavailable processors which means, a C++ program will not be able totake the advantages of the "Hyper Threading" instruction set of thePentium 4 HT processor. (Of course HT is outdated now...) It will alsonot be able to take advantages of the Core 2 duo or Core 2 Quad's "truemulti-threaded" instruction set as the compiler generated native codedoes not even know about these instruction sets.
In the earlierdays, not much changes were introduced to the instruction set withevery processor release. The advancement in the processor was only inthe speed and very few additional instruction sets with every release.Intel or AMD normally expects game developers to use these additionalinstruction sets. But with the advent of PIV and then on, with everyrelease, PIV, PIV HT, Core, Core 2, Core 2 Quad, Extreme, and thelatest Penryn, there are additional instruction sets that could beutilized if your application needs performance. There are C++ compilersthat generate code that targets specific processors. But thedisadvantage is the application has to be tagged as "This application'sminimum system requirements are atleast a Core 2 Quad processor" whichmeans a lot of customers will start to run away.
This is preciselywhere the C#'s framework compiler comes into picture. Because theapplication is compiled the second time at the user's site, theFramework knows about the actual running platform and is able togenerate code that runs the best on the given platform.
Point 2:So, then why doesn't *all* C# programs run faster?
C#or for that matter any .NET based application runs in a sand-boxedenvironment and hence many instructions have to be checked for safety.Because additional safety is not free, C# comes with a performanceoverhead, which means a program like,
for(inti=0;i<100000000;i++)
{
// pig function
Pig_Function();
}
wherePig_Function() is a really time consuming operation, C++ is faster by aorder of magnitude. Nearly all the threads I've seen that claims C++ isfaster writes a small application like this a prove that C++ is atleastn times faster than an equivalent c++ program and yes it's true.Microsoft does not recommend using C# for time-critical applications.
Point3: So when is C# really faster?
Awell designed C# program is more than 90% as fast as an equivalent"well-designed" C++ program. But the catch is "well-designing" a C++program. How many of us can manage memory efficiently in a C++application that's so huge say a million lines of code? It's extremelydifficult to "well-design" a C++ program especially when the programgrows larger. The problem with "not-freeing" the memory at the righttime is that the working set of the application increases whichincreases the number of "page faults". Everyone knows that page faultis one of the most time-consuming operation as it requires a hard diskaccess. One page fault and you are dead. Any optimization that you didspending your hours of time is wasted in this page fault because youdid not "free" memory that you no longer needed. A lot of classicalapplications including Google Picasa suffers from memory managementproblems. After about two or three days, you can notice that theseapplications become slower necessitating a Windows Restart. Thisproblem is completely alleviated in C#. the Framework comes with abroom behind you and sweeps your drop during the course of theexecution and as a result your working set never grows (unless youreally use it) which means lesser page faults. This means that"well-designing" a C++ program is far complicated than a equivalent C#program which is responsible for its sluggish performance.
So nowI can hear you asking me,
So to conclude what should I do?
That'sa nice question. Except for writing time-critical blocks of code,prefer C#. Write all your algorithmic code in C++ (notVC++ .NET), compile it into a dll and call that using a Dll Interopthrough C#. This should balance the performance. This technique is notnew or not invented by me or anyone. It's similar the old age Cprogramming vs Assembly, where people on one camp fight assemblyprogramming is faster and the other camp stating C is easier to developand then people started using assembly embedded within a C program fortime-critical applications using an asm block.
Historyrepeats...!
Mugunth
Originally Posted at my blog
http://tech-mugunthkumar.blogspot.com/2008/02/c-vs-cc-performance.html
History
Nothing much here.