Is managed c++ faster than normal c++ or c#?

You might be asking the wrong question.

It is always easier to write good (and faster) code in the language you are most familiar with.

If you are comfortable with C++, then the questions are:

Do you want/need garbage collection?

If you are programming games can you tolerate the non-deterministic nature of garbage collection, or will that impact real-time performance at some point?

What platform(s) are you targeting? Does compiling to the CLR help you with your choice of platforms or hinder you? If you want to target platforms that don't have CLR then native C++ is more portable. If you want to target Window phones, then I think CLR is recommended (required?).

What sort of resources are you talking about? Graphics? Video? Audio? What frameworks / libraries are you going to use to manipulate them? Do those frameworks / libraries offer better support / interfaces for managed or unmanaged code? Unless you are rolling your own library/framework for manipulating those resources, then that's probably going to be the thing that most influences your performance and also dictates your choice.

I've seen the article which says that C# uses generic optimizer, but C++/CLI uses a special C++/CLI optimizer which can make the code faster then C# in certain situations. Sorry, don't know how to find it… It could be a journal requiring subscription, maybe Dr.Dobbs…

—SA

Despite the runtime being the same for both C# and C++, there are performance-oriented tricks allowed in C++ language that have no equivalent C# (I mean compile-time programming[^], of course). Using some of these tricks, you could considerably improve efficiency of your program by shifting potentially runtime activity to compile time: the compiler will produce new code while expanding the templates that you provide.

Of course you can produce new code with C# as well, but you would need to emit your own CLR byte code to accomplish this. And if you resort to emitting your own byte code, the language in which you code it becomes very much irrelevant.

I did very lightweight side-by-side comparisons of managed and native 32-bit C++ programs some three years ago (I think it was a CPU-intensive contest-style programming problem, I don't remember the details). I was hoping to get some performance improvement by switching to native 32-bit mode, but I did not get any speed-up worth talking about: wall clock run time in both cases was roughly the same.

You should also consider what language you and your co-authors likes most, or code is available.

The truth is: Improving the speed is most a task of writing intelligent code, with optimized object creation, file access and most drawing. And you the right drawing API, like OpenGL and not GDI+. Or try both...

my favourite graphic links:
Update Region
Add fast user-extensible image processing support to CBitmap[^]
CxImage[^]
CBitmapEx - Free C++ Bitmap Manipulation Class[^]
ImageStone[^]