C++CLI. Are native parts written in pure C++ but compiled in CLI as fast as pure native C++?

I want to delegate audio computing to a C++ layer, but handle and edit audio content through a WPF GUI.

I have had a brief look at C++/CLI, and I wanted to know:

should I use C++/CLI as an intermediate layer between C# GUI and C++ audio management
or should I simply put my code in C++/CLI and expect it to be compiled the same way, thus as efficient.

EDIT: as the flaming war may begin. This is a link that goes to the benchmarks game, that clearly states the C/C++ as a speed winners. I am asking: Should I write my C++ in a C++ Dll, or in a C++CLI assembly.

Solution

In C++/CLI, managed types (ref class for example) and their members are compiled to MSIL. This means no use of SIMD, and much less optimization (at least in the current version of .NET, and the reasons given by Microsoft aren't changing any time soon, although they could change their assessment of the tradeoffs).

Native types, on the other hand, can be compiled either to MSIL or to native machine code. Although Visual C++ doesn't have the best C++ optimizer in the world, it's very very good. So my recommendation would be to compile to native code. Visual C++ will use C++ interop when calling in between managed and native code, which is very efficient (it's the same internalcall technology used for all .NET's built-in functions such as string concatenation).

To make this happen, you can either put your time-critical code in a separate object file (not separate DLL!, let the linker combine managed and unmanaged code together into a "mixed-mode" assembly) compiled without /clr, or bracket it with #pragma managed(push, off) ... #pragma managed(pop). Either way will get you maximum optimizations and allow you to use SIMD intrinsics for very speedy code.