What's the difference between the interop of C# and C++/CLI in .NET Core?

[huoyaoyuan]

Several years ago, before the public launch of .NET Core, I heard that C++/CLI can provide better interop performance than C#, thus used in places like WPF. Now in .NET Core we have many new unsafe API and manual marshalling to improve interop performance of C#. Is there still any key difference between IL and native (IJW) code? I assume that "pure" mode of C++/CLI should get merely the same performance of C#.

[jkotas]

cc @AaronRobinsonMSFT

[AaronRobinsonMSFT]

@huoyaoyuan This is a great question. It is something I am actively working with multiple stakeholders to define. Let's go through each point in your comment.

heard that C++/CLI can provide better interop performance than C#, thus used in places like WPF.

That is partially true. There was also a safety perspective when writing C++ and relying on the .NET runtime when appropriate. Making consuming C++ libraries, while avoiding COM, from .NET was another pillar. Herb Sutter's original white-paper can be found here.

Now in .NET Core we have many new unsafe API and manual marshalling to improve interop performance of C#. Is there still any key difference between IL and native (IJW) code?

From a performance perspective? Not a whole lot actually. In reality the performance win could get difficult to achieve as one mixed more and more C++ and C#. Staying in one or the other most of the time was the win because transitioning was always basically a P/Invoke or Reverse P/Invoke call - which can be expensive. The "it just works" portion was a curse and a blessing. The C++/CLI compiler would go above and beyond to make many scenarios "just work" and obscure the fact that it was likely better to just stay in managed code at the time or stay in C++ and perform an operation using low level functions, it was always a mix. However, if bulk operations were performed in one or the other then one could get high performance in the pure C++ and access to the .NET library ecosystem in the other.

I assume that "pure" mode of C++/CLI should get merely the same performance of C#.

For the most part yes, but recall that the best optimizations in any compiler rely on patterns. This is particularly true for the JIT which, like most compilers, recognizes patterns and when it does can produce optimal code. Since Roslyn is the most common CLI compiler the patterns it produces are what the JIT relies upon. The C++/CLI compiler on the other hand will not always produce the same patterns so can be slower even though it is all IL and the same JIT. Also note that pure is deprecated in .NET Core.

The potential pattern mismatch is compounded by the fact that C++/CLI hasn't really evolved since the 2005 timeframe. This means that the myriad of .NET intrinsics, common C# language idioms and newer types like Span<T> aren't accessible or expressible in C++/CLI.

The TL;DR of this is C++/CLI is fully supported and will continue to be for those customers that find success with it. It is still rock solid and the .NET runtime will continue to ensure it runs and can take advantage of what it can express. However, for optimum performance and tooling support writing ISO C++ and/or C# is ideal. The P/Invoke boundary exists for C style interop, it does make C++ cumbersome but is possible.

[huoyaoyuan]

Thank you for the explanation. I was thinking scenarios like porting WPF components to C# and saw people already starting to do that. By decompilation, I can find there are full of mangled C++ functions, function pointers and templates instantiates if C++/CLI code.
I think my knowledge is enough to understand the execution and marshalling by IL. There's no magic beyond.