.NET (C#) and the Arma 3 Game engine

[sbsmac]

The original question is a bit silly since no-one is likely to rewrite a very large codebase in a new language, particularly when

1) Your development team has lots of experience in the old language
2) It's 'common wisdom' that the new language is unsuitable for your application.

That said, someone made a very good point that there is no reason why you couldn't benefit from a change in language for new code/subsystems. The debate about managed vs unmanaged performance will probably never be settled by anything as prosaic as facts but probably the best analysis I've read is here http://www.codeproject.com/Articles/...-Csharp-vs-NET.

If you can't be bothered to read the whole thing the basic conclusion is that well-written C++ is faster (10-30%) than well-written C#. The real question is whether you're capable of writing sufficiently good code for it to matter and whether that part of your code is even performance-critical.

IMHO the most effective optimisations fall into two categories: either a very small tight loop which is executed repeatedly or a rethink of a high-level algorithm. Very rarely do you conclude that your program is just 'too slow' across the board. For a small loop, well you'd probably rewrite it in assembler anyway. At the other end of the scale I've found the support offered by C# and the .Net framework actually far more conducive to experimenting with alternative algorithms or data structures than when I used to use C++.

The other 'performance' complaint that is also raised is the non-determism introduce by the process of garbage collection. It's certainly true that this can be an issue. OTOH it is possible to structure critical sections of C# code to avoid creating large numbers of 'generation 1' objects which are the worst case for GC. It takes some effort to do this but somewhat less than the thought required to do 'manual' memory deallocation in an unmanaged language. (BTW, it is actually considerably faster to _allocate_ objects in a managed language due to the compaction of free memory into a single block).

I recently had the experience of starting a completely new development (comms stack) which had reasonably strict real-time requirements (<4ms response time). This is the kind of application where it's "obvious" that you should use C++. We started from the position that we would implement the 'control' layers in C# for productivity reasons and call out to C++ dlls where performance was critical. 8 months later we haven't had to fall back to C++ and my belief is that we have been considerably more productive with the language and framework than we would have been if we'd used C++. (And at least an order of magnitude more productive than the corresponding functionality we have had to implement in embedded C.)

On a separate point, it's no accident that Intellisense works well for C#. If you read or watch interviews with the language designers they frequently state that 'ease of development' is as important for a modern language as any other feature and they often tweak language features (such as 'async') with a view to how well Intellisense will work.

[.kju [PvPscene]]

ID moved from C to C++ at some point :P

Ref ie: http://fabiensanglard.net/doom3/interviews.php