Performance of Managed C++ Vs UnManaged/native C++

Question

I am writing a very high performance application that handles and processes hundreds of events every millisecond.

Is Unmanaged C++ faster than managed c++? and why?

Managed C++ deals with CLR instead of OS and CLR takes care of memory management, which simplifies the code and is probably also more efficient than code written by "a programmer" in unmanaged C++? or there is some other reason? When using managed, how can one then avoid dynamic memory allocation, which causes a performance hit, if it is all transparent to the programmer and handled by CLR?

So coming back to my question, Is managed C++ more efficient in terms of speed than unmanaged C++ and why?

Answer 1

Isn't C++/CLI a half interpreted language like Java?

Also, didn't someone post a study just yesterday that showed that GC systems are always slower than non GC?

Answer 2

There is no one answer to this. As a really general rule, native code will usually be faster, but 1) that's not always the case, 2) sometimes the difference is too small to care about, and 3) how well the code is written will usually make more difference than managed vs. unmanaged.

Edit: Managed code runs in a virtual machine. Basically, you start with a compiler that produces byte codes as output, then feed that to the virtual machine. The virtual machine then either interprets it or re-compiles it to machine code and executes that. Either way, you've added some overhead.

The VM also uses a garbage collector. Garbage collectors have rather different characteristics from manually managing memory. With most manual managers, allocating memory is fairly expensive. Releasing memory is fairly cheap, but roughly linear on the number of items you release.

With a garbage collector, allocating memory is typically very cheap. With a typical (copying) collector, the cost of releasing memory depends primarily upon the number of objects that have been allocated and are still (at least potentially) in use.

The allocations themselves also differ though. In native C++, you typically create most objects on the stack, where both allocating and releasing memory is extremely cheap. In managed code, you typically allocate a much larger percentage of memory dynamically, where it's garbage collected.

Answer 3

You can write slow code in any language; conversely, you can use decent algorithms that may well be fast is almost any language.

The common answer here would be to pick a language that you already know, use appropriate algorithms, then profile the heck out of it to determine the actual hot spots.

I am somewhat concerned about the hundreds of events every millisecond statement. That's an awful lot. Are you reasonably going to be able to do the processing you expect in any language?

As a C++ developer on high-performance systems, I tend to trust my ability to profile and optimize the emitted code. That said; there are very high performance .NET applications, where the writer has gone to great lengths to not do dynamic memory allocation inside the critical loops - mostly by using allocated pools of objects created beforehand.

So to repeat my previous comment: pick what you already know, then tune. Even if you hit a dead end; you will likely know much more about your problem space.

Answer 4

It all depends on the situation.

Things that make unmanaged code faster / managed code slower:

• the code needs to be converted to machine code before it can be executed
• garbage collection might cause an overhead
• calls from managed to unmanaged code have a serious overhead
• unmanaged compilers can optimize more since they directly generate machine code (seen myself)

Things that make managed code faster / unmanaged code slower:

• since the code is converted to machine code right before it's used, managed code can be optimized for the actual processor (with unmanaged code you have to target the 'minimum-supported' processor).

And probably there are many more reasons.

Answer 5

There are many good answers here, but one aspect of managed code that may give it an advantage in the long term is runtime analysis. Since the code generated by the managed compiler is an intermediate format, the machine code that actually executes can be optimized based on actual usage. If a particular subset of functionality is heavily used, the JIT'er can localize the machine code all on the same memory page, increasing locality. If a particular sub-call is made repeatedly from a particular method, a JIT'er can dynamically inline it.

This is an improvement over unmanaged code, where inlining must be "guessed" ahead of time, and excessive inlining is harmful because it bloats code size and causes locality issues that cause (very time-expensive) L2/L1 cache misses. That information is simply not available to static analysis, so it is only possible in a JIT'ing environment. There's a goody basket of possible wins from runtime analysis such as optimized loop unwinding, etc.

I'm not claiming the .NET JIT'er is as smart as it could be, but I know I've heard about global analysis features and I know a lot of research into runtime analysis has been done at Hewlett-Packard and other companies.