Performance with MS Vis C++ 2005 and /clr

This question is about native C++ efficiency when compiled together with .NET CLR
So I posted it here instead of the Windows forum. But may be I am wrong.

Please tell me if I well undesrtood:
If I a build a Windows Form using the designer and after I add much C/C++ native code which I want to be compiled to machine instructions (not MSIL) which run faster, I have to use the /clr compiler option and then use


#pragma managed
#pragma unmanaged
#pragma managed([push,] on | off)
#pragma managed(pop)

to force compiler to machine instructions when I want it

(1) But why doesn't the compiler compile all native code to machine instruction as a default if that runs faster?

(2) Does switch between machine instructions and MSIL consume much time? I guess it's quite difficult to evaluate when this switch makes loose more time than the one gained by using machin instructions

(3) I guess that a background thread not dealing with GUIs, written in native C++, is for sure convenient to be compiled with #pragma unmanaged directive ?

If I remember correctly from my class C# is the only language that can compile directly to native without going to MSIL first. Everything else, including C++, goes to MSIL first. This is all compile time overhead and should not be an issue during run time.

However speaking of C# if you compile C# to native code you lose all the benefits of MSIL and the fact that it only brings in the library functions that you actually use. As soon as you go native your C# executable grows exponentially because it brings in everything in the libraries you are using just as C++ does. And, unlike C++, because you've been relying on .NET and MSIL to speed your C# code up as soon as you compile to native you will see that speed disappear. It's quite possible to have a C# program in MSIL run much faster than the same code compiled down to native code. This is one huge disadvantage of C# because not many people are going to leave their code as MSIL since it can easily be reverse engineered. And then since C# compiled to native code will run slower than the MSIL version you pretty much lose all the nice benefits C# offers when it comes to speed under .NET.

You will want your code compiled as native and not MSIL. Although the relationship between C++ .NET and MSIL is not 1 to 1 it may still be very easy to reverse engineer a C++ .NET MSIL file. With a C# app you definitely want native code if you are releasing the product because there is a 1 to 1 relationship between MSIL and C# code. In fact there are many MSIL assemblers and disassemblers freely available that will take any MSIL file and convert it to C# and vice versa. Not good for a released product.

There are a few reasons C++/CLI is not compiled to native by default.

1) Security and code restrictions. Native code cannot be controlled by the VM, so it can do anything it wants. This, in turn, means that you can bypass the VM's security system, which means that the VM will only execute native code if the calling code has the universal permission anyway. If your program does not have this permission, it cannot run native code.

2) Security and code correctness. Byte code is run through a verifier at JIT time, which ensures that it cannot possibly create out-of-bounds memory accesses. The same cannot be done with native code, so there's a security issue there.

3) Compactness. MSIL is a lot smaller than native code. Native code is register-based, MSIL stack-based, and stack-based code is generally smaller. The JITter can create exception tables and garbage collection root lists at runtime; with native code, these must be stored in the executable. This makes for larger executables and longer startup (the VM has to start anyway, and CPU vs disk speeds are so out of proportion these days that it probably takes longer to read a large executable from disk than to read the smaller byte code and JIT it).

4) Optimization. MSIL can be recompiled with profiling information gathered during the program execution, to lead to more efficient native code. If the code is native in the first place, it cannot be optimized any more.

5) Last, and in MS's view probably least too, portability. MSIL can be run by .Net VMs of other platforms (Mono or DotGNU), native code is bound to a CPU and often to a platform.