3

Will Unmanaged code (CPP) operated by Managed code (C#) have the same preformance as if it was operated by another unmanaged code (does the stack operate the same etc)?

I.e. - If I call code in MyCppApp from MyCs will it have the same performance as if it was called from MyCpp2App?

I am aware of the toll of the interop actions, but leaving those aside, My question is on performance of the CPP code execution itself.

Thanks, S

2 Answers2

2

Once control is in unmanaged code the fact that is called by managed code does not have any influence over what the CPU does. The CPU executes the same instructions regardless of the caller. In fact the CPU has no notion of a "caller".

Therefore performance is the same no matter who calls a piece of code. (Assuming, calling costs are zero.)

usr
  • 168,620
  • 35
  • 240
  • 369
  • I agree. Do you think you can find a reference to that in MS (or other) literature? – Joezer May 25 '14 at 15:47
  • To me this fact is totally obvious. I don't know why you would need an "authoritative" reference here. CPUs do not have a "slow" mode that managed code sets to on. How could the caller possibly influence a different piece of code that executes the same instructions regardless of caller?! – usr May 25 '14 at 15:58
  • 2
    Hmm, it is not as simple as it looks. The GC suspends threads to do its job. Which can certainly happen while the native code is executing, triggered by an allocation in another thread. Whether the native code gets suspended immediately or when it re-enters managed code is a bit immaterial, you just can't see the difference. The premise of the question is a broken assumption. – Hans Passant May 25 '14 at 16:56
  • @HansPassant Good points. Does the GC suspend threads while *in* native code? Or *only* on return? I suspect it only briefly halts everything to install the return trap. That would leave native performance almost unaffected. In the same reasoning you could say that other managed activity might cause more page faults in native code and therefore reduces its performance. I think that's not in the spirit of this question. – usr May 25 '14 at 17:55
  • 1
    @usr When compiling a DLL with mixed code, unless you are very careful to push and pop managed state even the "unmanaged" code will be compiled to unsafe CLR instructions not native instructions and thus must still be JITed. If you are careful about managed state then you have the overhead of a P/Invoke, which is not insignificant even if most of the marshalling that would normally be done is left to the developer. – Mgetz Jun 02 '14 at 11:16
1

Yes, but keep in mind, that invoking the un-managed application may take longer, since data need to be copied from managed to un-managed buffers.

This is one of the issues with .NET and COM interop - the problem is in the number of instructions (~50) that have to be executed in order to get out of the managed environment - this making the whole process somewhat slow.

Also take not, that in the ultimate phase, managed code will be translated to appropriate machine code using JIT compilation.

Andro
  • 2,232
  • 1
  • 27
  • 40
  • 1
    Hi Candyman, What do you mean by "of course"? of course yes, or of course no? I am aware of the toll of the interop actions, BUT that is not the questions. My question is on performance of the CPP code execution itself, will it be any different performance-wise (and if so, why?) I hope the Q is clearer now –  May 25 '14 at 15:17
  • 1
    I'm sorry not not being clear. Unmanaged code itself will perform just as fast once it was appropriately initialized by the managed platform. I mean why wouldn't it be - the managed platform will not emulate it so it will be execute on the real machine anyway. – Andro May 25 '14 at 15:19
  • That's my question, I'm just asking because a fellow dev team expressed that it would run slower due to stack being utilized differentely. That didn't sound right to me but I was not 100% sure to say that they were wrong. So basically you say there is not reason it should act differently? –  May 25 '14 at 15:24
  • That is what I am saying. – Andro May 25 '14 at 15:27