C++ vs. C# 2010 ... and the winner is ...

As far as I know there is no World Cup for programming languages, quadrennial or otherwise. No FIFA++ or FIFA# either. But, if there was...

I have been helping for several months with a project aiming to commercialise an optimising technique for microelectronic circuits discovered as part of some academic research at a local university. Who would predict that the mathematics of Galois polynomials would have an industrial application?! Well, this is my journal of total obscurity.

Writing the software. Apart from user interface, visualisation and usability all good stuff, a key element of the project is of course the algorithms, some of which require a lot of computational processing by current standards and can be time consuming (potentially days rather than hours or minutes).

The original research software used a C++ with STL implementation and much of the time I continued using C++ for algorithm work as an adaption of the original despite the fact I’m far more C# oriented nowadays. Mental exercise is a good thing. My Windows software design was a hybrid with the user interface and control functionality in C#/.Net/WPF with algorithms packaged in a DLL implemented in C++. Standard .Net interop linked the two components together.

I suspect most developers with strong experience in C++ and C# will agree that a modern language such as C# can be far more readable than C++. However a common concern is the efficiency of C# on the .Net and Mono environments using the Common Library Runtime (CLR) compared with C++ static compilation into native machine code. There is no question that C and C++ work closer to the metal and their compilers generate very efficient code in the right hands (C has been around since 1973 and C++ since 1983). The C/C++ combination remains the most efficient programming choice for some applications.

Question. What happened when I rewrote a key algorithm from C++ into C# using the same logic?

Answer. Performance improved by an order of magnitude. In fact my initial benchmarks were so close to exactly 10x faster I felt obliged to check and recheck. Memory usage for the C# version was about 5% less than C++ for this specific problem.

[In both instances C++ and C# I used Microsoft Visual Studio 2010 and .Net 4 runtimes but have since replicated similar figures on Linux using GNU CPP for C++ and MonoDevelop 2.2 with Mono 2.6.4 for C#.].

Understanding the why. Partly down to inefficiencies in the C++ heap and STL templates - software uses hashset/unordered_map/vector objects. Partly benefits of automatic lifecycle management of C# objects with a built in garbage collector. A little benefit from C# language features such as the foreach construction.

OK, I’m sure that by adjusting algorithms and replacing STL constructs I could bring C++ up to a similar or higher speed than the C# version. Plenty can be said on that topic. But life is too short for such antics especially when the C# version is more concise and readable that a C++ version could ever be.

Back in 2006 Italy lifted the trophy, C# and CLR implementations were not as mature, C++ held sway. Times change.

Now, Summer 2010, to my mind C# takes the top of the podium. Weighing the evidence, fact not opinion. Performance and elegance, it is so often a trade off but this, my recent experiment, sealed the question for me.

Postscript. I wrote this note to encourage other developers to look again at the rationale of choosing C++ over a modern programming language even for computationally intensive tasks. The usual caveats. Especially 1. existing systems where language change is impractical and interop inappropriate and 2. the limited class of problem where C++ still rules.  Personally speaking. I'll continue to choose C or C++ where there is a clear benefit but the problem domain where this is true seems to have shrunk dramatically.