any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).
This isn't true, by the way. In .NET, the first time you run a method it is compiled to native code and replaced in what amounts to the v-table. Any additional calls to that method will be native. So accessing "code" is nearly identical for managed as it is for native.
In addition, memory allocation in C++ is significantly slower than in C#. This is because the C++ allocator must traverse the designated user-mode address space looking for an available chunk of memory that's large enough to fit the size of memory you're trying to allocate. The longer your application runs, the more fragmented memory becomes and potentially the more difficult this will be, especially if you're leaking memory. With that said, a lot of people write their own allocator for C++ applications.
In C#, all memory is compressed and the next available block of memory is always pointed to by a reference. So allocating memory in C# is constant time, and almost instantaneous. With that said, attempting to allocate memory beyond the current generational cap does invoke a garbage collection, which can cause intermittent issues. But, proper memory management, allocating small bits at a time, etc... can cause the generations to change size over time and can result in very fast garbage collections.
Finally, when you compile your C++ code to machine language, the compiler is unable to make a large number of optimizations because it knows nothing about the machine your application will be running on. So it has to accept the "lowest common denominator" with respect to advanced CPU features. In contrast, when a .NET application is JIT compiled, it is compiled on the user's machine. Because of this, JIT compiled code can be significantly faster than code compiled natively on a dev's machine.
While it's true the .NET CLR still needs to leverage some of those available optimizations, which it likely does with VS 2012, it is untrue that a VM will always be slower than native code.
Oh, and on a related note, SharpDX generates binding assemblies from the DirectX headers/libraries without using C++/CLI wrappers. As a result, it's known to be significantly faster than SlimDX. It's also compatible with Windows 8 Metro Apps.