Why is native c++ performing poorly with c++ interop? - c++

Question

I have posted some code below to test the performance (time-wise in milliseconds) of calling a method from native c++ and c# from c++/cli using Visual Studio 2010. I have a separate native c++ project which is compiled into dll. When I call into c++ from c++, I get the expected result which is much faster (about 4x) than the managed counterparts. However, when I call into c++ from c++/cli, the performance is 10x slower.
Is this an expected behavior when calling into native c++ from c++/cli? I was under the impression that there shouldn't be a significant difference, but this simple test is showing otherwise. Could this be an optimization difference between the c++ and c++/cli compiler?
Update
I made some update to the cpp, so that I'm not calling a method in a tight loop (as Reed Copsey pointed out), and it turns out that the difference in performance in insignificant or very small. Depending on how the inter-operation is being done, of course.
.h
#ifndef CPPOBJECT_H
#define CPPOBJECT_H
#ifdef CPLUSPLUSOBJECT_EXPORTING
#define CLASS_DECLSPEC __declspec(dllexport)
#else
#define CLASS_DECLSPEC __declspec(dllimport)
#endif
class CLASS_DECLSPEC CPlusPlusObject
{
public:
CPlusPlusObject(){}
~CPlusPlusObject(){}
void sayHello();
double getSqrt(double n);
// Update
double wasteSomeTimeWithSqrt(double n);
};
#endif
.cpp
#include "CPlusPlusObject.h"
#include <iostream>
void CPlusPlusObject::sayHello(){std::cout << "Hello";}
double CPlusPlusObject::getSqrt(double n) {return std::sqrt(n);}
double CPlusPlusObject::wasteSomeTimeWithSqrt(double n)
{
double result = 0;
for (int x = 0; x < 10000000; x++)
{
result += std::sqrt(n);
}
return result;
}
c++/cli
const unsigned set = 100;
const unsigned repetitions = 1000000;
double cppcliTocpp()
{
double n = 0;
System::Diagnostics::Stopwatch^ stopWatch = gcnew System::Diagnostics::Stopwatch();
stopWatch->Start();
while (stopWatch->ElapsedMilliseconds < 1200){n+=0.001;}
stopWatch->Reset();
for (int x = 0; x < set; x++)
{
stopWatch->Start();
CPlusPlusObject cplusplusObject;
n += cplusplusObject.wasteSomeTimeWithSqrt(123.456);
/*for (int i = 0; i < repetitions; i++)
{
n += cplusplusObject.getSqrt(123.456);
}*/
stopWatch->Stop();
System::Console::WriteLine("c++/cli call to native c++ took " + stopWatch->ElapsedMilliseconds + "ms.");
stopWatch->Reset();
}
return n;
}
double cppcliTocSharp()
{
double n = 0;
System::Diagnostics::Stopwatch^ stopWatch = gcnew System::Diagnostics::Stopwatch();
stopWatch->Start();
while (stopWatch->ElapsedMilliseconds < 1200){n+=0.001;}
stopWatch->Reset();
for (int x = 0; x < set; x++)
{
stopWatch->Start();
CSharp::CSharpObject^ cSharpObject = gcnew CSharp::CSharpObject();
for (int i = 0; i < repetitions; i++)
{
n += cSharpObject->GetSqrt(123.456);
}
stopWatch->Stop();
System::Console::WriteLine("c++/cli call to c# took " + stopWatch->ElapsedMilliseconds + "ms.");
stopWatch->Reset();
}
return n;
}
double cppcli()
{
double n = 0;
System::Diagnostics::Stopwatch^ stopWatch = gcnew System::Diagnostics::Stopwatch();
stopWatch->Start();
while (stopWatch->ElapsedMilliseconds < 1200){n+=0.001;}
stopWatch->Reset();
for (int x = 0; x < set; x++)
{
stopWatch->Start();
CPlusPlusCliObject cPlusPlusCliObject;
for (int i = 0; i < repetitions; i++)
{
n += cPlusPlusCliObject.getSqrt(123.456);
}
stopWatch->Stop();
System::Console::WriteLine("c++/cli took " + stopWatch->ElapsedMilliseconds + "ms.");
stopWatch->Reset();
}
return n;
}
int main()
{
double n = 0;
n += cppcliTocpp();
n += cppcliTocSharp();
n += cppcli();
System::Console::WriteLine(n);
System::Console::ReadKey();
}

Answer 1

However, when I call into c++ from c++/cli, the performance is 10x slower.
Bridging the CLR and native code requires marshaling. There is always going to be some overhead in each method call when going from C++/CLI into a native method call.
The only reason the overhead (in this case) seems so large is that you're calling a very fast method in a tight loop. If you were to batch the class, or call a method that was significantly longer in terms of runtime, you'd find that the overhead is quite small.

Answer 2

These micro-benchmarks are very dangerous. You made an effort to avoid the typical benchmark mistakes but still fell into a classic trap. Your intention was to measure method call overhead, but that's not what's actually happening. The jitter optimizer is capable of standard code optimization techniques, like code hoisting and method inlining. You can only really see that when you look at the generated machine code. Debug + Windows + Disassembly window.
I tested this with VS2012, 32-bit Release build with the jitter optimizer enabled. The C++/CLI code was the fastest, taking ~128 msec:
000000bf fld qword ptr ds:[01212078h]
000000c5 fsqrt
000000c7 fstp qword ptr [ebp-20h]
//
// stopWatch->Start() call elided...
//
n += cPlusPlusCliObject.getSqrt(123.456);
000000f5 fld qword ptr [ebp-20h]
000000f8 fadd qword ptr [ebp-14h]
000000fb fstp qword ptr [ebp-14h]
for (int i = 0; i < repetitions; i++)
000000fe dec eax
000000ff jne 000000F5
In other words, the std::sqrt() call got hoisted out of the loop and the inner loop simply performs adds from the generated value. No method call. Also note how it didn't actually measure the time needed for the sqrt() call :)
The loop with the C# method call was a bit slower, taking ~180 msec:
000000ea fld qword ptr ds:[01211EC0h]
000000f0 fsqrt
000000f2 fadd qword ptr [ebp-14h]
000000f5 fstp qword ptr [ebp-14h]
for (int i = 0; i < repetitions; i++)
000000f8 dec eax
000000f9 jne 000000EA
Just the inlined method call to Math::Sqrt(), it didn't get hoisted. Not actually sure why, the optimizations performed by the jitter optimizer do have a time factor included.
And I won't post the code for the interop call. But yes, taking ~380 msec due to the need to actually make a function call, unmanaged code cannot be inlined, plus the thunk that's required to prevent the garbage collector from blundering into the unmanaged stack frame. The thunk is pretty fast, takes a handful of nanoseconds, but that just can't compete with the jitter optimizer directly inlining the fadd or fsqrt.