Does C++/CLI really has better performace than C#
-
I did a small test: create a default project using VS2005 wizard respectively in C++/CLI and C#, which displays a dummy winform. No code added, no change made. Compile and run both of them. Here's the observation: File size: cppclr.exe 35k(release) / 38k(debug) csharp.exe 16k(release) / 16k(debug) memory usage: cppclr.exe 11,164k(release) / 17,500k(debug) csharp.exe 10,588k(release) / 9,136k(debug) What happened there?
edger wrote:
What happened there?
C# compiles smaller and take up less memory.
Blog Have I http:\\www.frankkerrigan.com
-
edger wrote:
What happened there?
C# compiles smaller and take up less memory.
Blog Have I http:\\www.frankkerrigan.com
:laugh:
--[:jig:]-- [My Current Status] Link2006 wrote:Let's take it outside of CP Jeremy : Please don't.I would love to see this.I'm making the popcorn already.
-
edger wrote:
What happened there?
C# compiles smaller and take up less memory.
Blog Have I http:\\www.frankkerrigan.com
Perfect.
-
I did a small test: create a default project using VS2005 wizard respectively in C++/CLI and C#, which displays a dummy winform. No code added, no change made. Compile and run both of them. Here's the observation: File size: cppclr.exe 35k(release) / 38k(debug) csharp.exe 16k(release) / 16k(debug) memory usage: cppclr.exe 11,164k(release) / 17,500k(debug) csharp.exe 10,588k(release) / 9,136k(debug) What happened there?
Have you compiled the C++/CLI solution with the /clr:pure compiler switch? The default setting is /clr which does a lot more for native/managed interop.
-
I did a small test: create a default project using VS2005 wizard respectively in C++/CLI and C#, which displays a dummy winform. No code added, no change made. Compile and run both of them. Here's the observation: File size: cppclr.exe 35k(release) / 38k(debug) csharp.exe 16k(release) / 16k(debug) memory usage: cppclr.exe 11,164k(release) / 17,500k(debug) csharp.exe 10,588k(release) / 9,136k(debug) What happened there?
What fuels language wars is that I'm sure it's possible to pick a benchmark whereby VB6 is as fast as C++. Only a fool would claim that C++/CLI is faster than C# for EVERY trivial application one might contrive to use as a benchmark. Having said that, you were testing memory usage and exe size, not performance. And you were, obviously, not testing those things on a real world app, but you mainly tested the baggage that both have before they start doing anything.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
What fuels language wars is that I'm sure it's possible to pick a benchmark whereby VB6 is as fast as C++. Only a fool would claim that C++/CLI is faster than C# for EVERY trivial application one might contrive to use as a benchmark. Having said that, you were testing memory usage and exe size, not performance. And you were, obviously, not testing those things on a real world app, but you mainly tested the baggage that both have before they start doing anything.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
That's fair. In fact, I did not meant to light up a war. That's not language comparison either. It's totally wrong. My initial curiosity is since 1)these wizard-generated apps do the same thing(even the code is almost the same) and 2）both were compiled to CLR, they are supposed to be approx. the same size. But they are not, it seems the c++ version links something more, and what are they? I chose the wrong title:sigh:
-
Have you compiled the C++/CLI solution with the /clr:pure compiler switch? The default setting is /clr which does a lot more for native/managed interop.
Well, it's a completely CLR app. no native code. the title is wrong, it's not about performance. it's about what extra gear C++ carries by default than a C# in a basic winform app.
-
Well, it's a completely CLR app. no native code. the title is wrong, it's not about performance. it's about what extra gear C++ carries by default than a C# in a basic winform app.
edger wrote:
Well, it's a completely CLR app. no native code.
It doesn't matter whether or not you have any native code in your source, the compiler still produces a mixed imaged. Therefore you always start with some overhead if you don't set the compiler switch to /clr:pure (or /clr:safe). C# always creates managed assemblies, C++/CLI creates mixed ones by default. Therefore you have a different entry point and start up code.
-
That's fair. In fact, I did not meant to light up a war. That's not language comparison either. It's totally wrong. My initial curiosity is since 1)these wizard-generated apps do the same thing(even the code is almost the same) and 2）both were compiled to CLR, they are supposed to be approx. the same size. But they are not, it seems the c++ version links something more, and what are they? I chose the wrong title:sigh:
edger wrote:
these wizard-generated apps do the same thing
Not really, as others have posted already, the C# compiler produces an MSIL image, while the C++ compiler produces a mixed mode image (capable of directly using native types).
edger wrote:
both were compiled to CLR, they are supposed to be approx. the same size.
If you want equivalent conditions, change the C++ compiler mode to /clr:safe (this is same as what you get with C#).
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
What fuels language wars is that I'm sure it's possible to pick a benchmark whereby VB6 is as fast as C++. Only a fool would claim that C++/CLI is faster than C# for EVERY trivial application one might contrive to use as a benchmark. Having said that, you were testing memory usage and exe size, not performance. And you were, obviously, not testing those things on a real world app, but you mainly tested the baggage that both have before they start doing anything.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
Only a fool would claim that C++/CLI is faster than C# for EVERY trivial application one might contrive to use as a benchmark.
In this case, the O.P. seems confused why the C++ compiler produces a larger app that consumes more memory. The size of the app, and its memory consumption may not always be a good indicator of performance. So overall, his tests are not very accurate.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
edger wrote:
these wizard-generated apps do the same thing
Not really, as others have posted already, the C# compiler produces an MSIL image, while the C++ compiler produces a mixed mode image (capable of directly using native types).
edger wrote:
both were compiled to CLR, they are supposed to be approx. the same size.
If you want equivalent conditions, change the C++ compiler mode to /clr:safe (this is same as what you get with C#).
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Nishant Sivakumar wrote:
the C# compiler produces an MSIL image, while the C++ compiler produces a mixed mode image (capable of directly using native types).
Thanks, learned something new.
Nishant Sivakumar wrote:
change the C++ compiler mode to /clr:safe (this is same as what you get with C#).
Tried that, it's different in the other way now, the file size is only 7k！
-
edger wrote:
Well, it's a completely CLR app. no native code.
It doesn't matter whether or not you have any native code in your source, the compiler still produces a mixed imaged. Therefore you always start with some overhead if you don't set the compiler switch to /clr:pure (or /clr:safe). C# always creates managed assemblies, C++/CLI creates mixed ones by default. Therefore you have a different entry point and start up code.
ABuenger wrote:
It doesn't matter whether or not you have any native code in your source, the compiler still produces a mixed imaged. Therefore you always start with some overhead if you don't set the compiler switch to /clr:pure (or /clr:safe). C# always creates managed assemblies, C++/CLI creates mixed ones by default. Therefore you have a different entry point and start up code.
Thanks, the default setting is /clr:pure, however you are right if switched to /clr:safe, it shrinks to 7k now.
-
I did a small test: create a default project using VS2005 wizard respectively in C++/CLI and C#, which displays a dummy winform. No code added, no change made. Compile and run both of them. Here's the observation: File size: cppclr.exe 35k(release) / 38k(debug) csharp.exe 16k(release) / 16k(debug) memory usage: cppclr.exe 11,164k(release) / 17,500k(debug) csharp.exe 10,588k(release) / 9,136k(debug) What happened there?
First you can write bad code in any language, and good code in any language. There is no guarentee in any 3rd party operation what the system did. However, just to nitpick.... you said "better performance" yet listed memory overhead which has little to do with performance. There is no way to know what you have until you benchmark it for more than simple applications. All it takes is one poorly formed function used often in any language (not isolating C# or C++ here because it could go either way), and you tip the balance. In the end use the language that is best for your application. That is not always C#, that is not always C++. You are still limited to your knowledge and skill and when applying them to a project you are applying your bias as well as the bias of the library designers you are applying to your project. That could be bad. I have had to, several times over the life of my project, rewritten functions/classes because they were poorly written from 3rd parties. This is the world you live in when you live on the performance edge. Profile the result, find the bottle-neck and evaluate how to fix the bottle-neck. It is a never ending process because when you remove one bottle-neck it simply moves elsewhere. This applies to all languages you choose to accept a performance struggle. Who wins in a performance battle is up to your skill/experience/knowledge applied on a grand scale to others. Time to fix something is another issue. It may be too expensive to fix a bottleneck, that is something you decide as a project manager, or senior developer, or at least provide the information as a developer to the person making the decision.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I did a small test: create a default project using VS2005 wizard respectively in C++/CLI and C#, which displays a dummy winform. No code added, no change made. Compile and run both of them. Here's the observation: File size: cppclr.exe 35k(release) / 38k(debug) csharp.exe 16k(release) / 16k(debug) memory usage: cppclr.exe 11,164k(release) / 17,500k(debug) csharp.exe 10,588k(release) / 9,136k(debug) What happened there?
There was a recent "shoot off" between Raymon Chen and (I believe) Lippman or soe othre C#/.NET guy, optimizing Raymonds Dictionary sample. Note that this is unmanaged vs. managed, not quite what you asked. But the outcome should be interesting nonetheless: (roughly, from memory): - for low investment, C# is as good as unmanaged C++ - when investing more, cost of C++ optimizations rises faster than cost of C# optimizations - Raymond finally won with no chance to beat him after he used a custom memory allocator (The C++ version now completed in the time it took the CLI runtime to start) Would find you a link, but internet access is weird here...
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighist