C# vs C/C++ Performance

Introduction

Well, this is my first post in this technology series. In fact, the title of this post, forced me to start of a technology focused blog. Well said about all these, let's now jump into the issue.

There has been a lot of heated discussion on different forums, newsgroups, and various other threads about the above topic. Now why should I discuss about the same again here?

Well, though there are many discussion groups that claim C++ to be faster and efficient, a small group of people still claim C# to be more efficient.
How the hell can a language that is not compiled to a native code be faster that a C++ binary?

Though the above statement is perfectly valid from the point of C++ programmers, I would like to highlight a few points that could state why some (not all) C# programs are *really faster* than it's equivalent C++ programs.

Point 1: C# is compiled twice. Once while the program is written and second when the program is executed at the user's site. The first compilation is done by your C# builder and the second by the .NET Framework on the user's machine. The reason why C# compiled applications could be faster is that, during the second compilation, the compiler knows the actual run-time environment and processor type and could generate instructions that targets a specific processor. Classical C++ compilers generate native code that is usually the Lowest Common Denominator of all the available processors which means, a C++ program will not be able to take the advantages of the "Hyper Threading" instruction set of the Pentium 4 HT processor. (Of course HT is outdated now...) It will also not be able to take advantages of the Core 2 duo or Core 2 Quad's "true multi-threaded" instruction set as the compiler generated native code does not even know about these instruction sets.
In the earlier days, not much changes were introduced to the instruction set with every processor release. The advancement in the processor was only in the speed and very few additional instruction sets with every release. Intel or AMD normally expects game developers to use these additional instruction sets. But with the advent of PIV and then on, with every release, PIV, PIV HT, Core, Core 2, Core 2 Quad, Extreme, and the latest Penryn, there are additional instruction sets that could be utilized if your application needs performance. There are C++ compilers that generate code that targets specific processors. But the disadvantage is the application has to be tagged as "This application's minimum system requirements are atleast a Core 2 Quad processor" which means a lot of customers will start to run away.
This is precisely where the C#'s framework compiler comes into picture. Because the application is compiled the second time at the user's site, the Framework knows about the actual running platform and is able to generate 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-boxed environment and hence many instructions have to be checked for safety. Because additional safety is not free, C# comes with a performance overhead, which means a program like,

for(int i=0;i<100000000;i++)
{
// pig function
Pig_Function();
}

where Pig_Function() is a really time consuming operation, C++ is faster by a order of magnitude. Nearly all the threads I've seen that claims C++ is faster writes a small application like this a prove that C++ is atleast n times faster than an equivalent c++ program and yes it's true. Microsoft does not recommend using C# for time-critical applications.

Point 3: So when is C# really faster?
A well 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 extremely difficult to "well-design" a C++ program especially when the program grows larger. The problem with "not-freeing" the memory at the right time is that the working set of the application increases which increases the number of "page faults". Everyone knows that page fault is one of the most time-consuming operation as it requires a hard disk access. One page fault and you are dead. Any optimization that you did spending your hours of time is wasted in this page fault because you did not "free" memory that you no longer needed. A lot of classical applications including Google Picasa suffers from memory management problems. After about two or three days, you can notice that these applications become slower necessitating a Windows Restart. This problem is completely alleviated in C#. the Framework comes with a broom behind you and sweeps your drop during the course of the execution and as a result your working set never grows (unless you really 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 now I can hear you asking me,
So to conclude what should I do?
That's a nice question. Except for writing time-critical blocks of code, prefer C#. Write all your algorithmic code in C++ (not VC++ .NET), compile it into a dll and call that using a Dll Interop through C#. This should balance the performance. This technique is not new or not invented by me or anyone. It's similar the old age C programming vs Assembly, where people on one camp fight assembly programming is faster and the other camp stating C is easier to develop and then people started using assembly embedded within a C program for time-critical applications using an asm block.

History repeats...!

Mugunth

Originally Posted at my blog

http://tech-mugunthkumar.blogspot.com/2008/02/c-vs-cc-performance.html

History

Nothing much here.