Improving performance C++/C#

[Olaf Baeyens]

Because of historical reasons, I have both C# and C++ managed/unmanaged code
mixed together in my class library.
But I prefer to port code to C# since it compiles faster and the syntax is
much more readable so I can do more in less time.

The big question now, will I gain/lose performance, given the fact that I
create pure managed code, if I port the managed C++ classes to C# classes? I
cannot port all the classes at once, too much to port, not enough time.

I use the C++ and C# standard edition 2003. For C++ no speed optimizing is
possible, but since C# uses the C# compiler from the .NET framework, I might
have faster speed this way?

[Carl Daniel [VC++ MVP]]

Ioannis Vranos wrote:

Carl Daniel [VC++ MVP] wrote:

To an extent, this is already happening with .NET.

What mechanism does C# provide for inclusion of source code files?

None. I don't think I implied that it did include any.

Rather, C# provides a module concept that works. That concept can only be
simulated through header conventions in native C++.

-cd

[Dan]

Olaf Baeyens wrote:

The C# compiler is quite speedy and easy to use on smallish projects,
but
when the project gets large (100's to 1000's of source files), the lack

of

a

real incremental build tips heaviliy in favor of C++ (except for
Rebuild-All, of course).

My own experience is that, with a decent machine (not super, just fairly
decent), we can recompile one of our project's code bases from scratch
(consisting of about 50.000 lines of code and about 250 source files that
compile into about 25 dlls) in less than a minute with the C# compiler.

The

larger code base (around 250.000 lines of code) used to be compilable from
scratch in a couple of minutes or so...

It's not bad, really. However, the project model, overall, usually causes

a

fairly big recompile when you change one of the bottom dependencies, which
can slow the process down.

The same is true in C++. Change one constant, or accidentily type a space in
one of the base headers and I am off agin for another 17 minute recompile.
I have a code base of about 180.000 lines now.

If the C++ people could find a way to avoid this "#include system" and use
the C# like technology then it would help a lot from developer viewpoint in
speeding up development.

In Whidbey it's done with using namespace keywords. e.g. using namespace
System::Windows ::Forms;

[Ioannis Vranos]

Carl Daniel [VC++ MVP] wrote:

What mechanism does C# provide for inclusion of source code files?

None. I don't think I implied that it did include any.

Rather, C# provides a module concept that works. That concept can only be
simulated through header conventions in native C++.

When you are talking about module concept, do you mean the dlls?

--
Ioannis Vranos

[Carl Daniel [VC++ MVP]]

Ioannis Vranos wrote:

When you are talking about module concept, do you mean the dlls?

I mean a system with rich meta-data that allows a "client" to be compiled
without needing the source code of the "server". That's the big weakness in
traditional C/C++ - there is no "module" concept that defines a body of
functionality with a clearly defined interface. Instead all we have is a
text-pasting system that can simulate real modules through convention.

In systems that have a cleanly defined module concept (e.g. Borland's
Delphi), changes to the implementation of a module rarely (or
never)necessita te re-compilation of clients of the module. In C and C++,
since all we have to track dependencies is file modification time, there's
simply no way for the compiler to know if a change requires recompilation of
clients or not, so it must take the conservative route and assume that all
changes (to a shared file) are important to clients.

The fact that C++ puts the implementation of the class, even if it's
private, into the field of view of clients further aggravates the situation.
In that regard, I'm not sure that .NET has done enough to shield clients
from internals changes to classes they consume, but it's a big step in the
right direction.

-cd

[Ioannis Vranos]

Carl Daniel [VC++ MVP] wrote:

I mean a system with rich meta-data that allows a "client" to be compiled
without needing the source code of the "server". That's the big weakness in
traditional C/C++ - there is no "module" concept that defines a body of
functionality with a clearly defined interface. Instead all we have is a
text-pasting system that can simulate real modules through convention.

In systems that have a cleanly defined module concept (e.g. Borland's
Delphi), changes to the implementation of a module rarely (or
never)necessita te re-compilation of clients of the module. In C and C++,
since all we have to track dependencies is file modification time, there's
simply no way for the compiler to know if a change requires recompilation of
clients or not, so it must take the conservative route and assume that all
changes (to a shared file) are important to clients.

The fact that C++ puts the implementation of the class, even if it's
private, into the field of view of clients further aggravates the situation.
In that regard, I'm not sure that .NET has done enough to shield clients
from internals changes to classes they consume, but it's a big step in the
right direction.

I do not know much on the subject, but in.NET specifically, one may
create dlls and use them, with no recompilation needed.

--
Ioannis Vranos

[Carl Daniel [VC++ MVP]]

Ioannis Vranos wrote:

I do not know much on the subject, but in.NET specifically, one may
create dlls and use them, with no recompilation needed.

Exactly - that's why I say it's a step in the right direction. I'm not sure
it's the complete answer, but it's better than #include.

-cd

[Willy Denoyette [MVP]]

See inline ***.

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Willy Denoyette [MVP] wrote:

Managed C++/CLI producing 25% faster code than C#. Any resources that
prove this claim?

Mentioned in:

http://microsoft.sitestream.com/Tech...V333_Sutte.ppt
http://www.accu.org/conference/prese..._(keynote).pdf
and in various other places.

****
Ok, but this doesn't prove the claim, it's just the source of all claims. I
was there at teched and when asked about the 25% difference, the answer I
got was - if this was true, the C# compiler team would have done a lousy job
:-).
Anyway, all benchmarks I have done indicate differences in performance in
between +5% and -5% (yes, sometimes C# is faster).
For real world applications the performance difference is neglectable, don't
forget that the BCL is all written in C#, and the CLR just sits in top of
the same C runtime and Win32.
Don't get me wrong C++/CLI is a great language extension and C++ my language
of choice, but execution speed is not the differentiator when comparing with
other managed languages.

Also many articles mention that VC++ compiler produces compile-time
optimised code in addition to CLR runtime MSIL optimisation, and has much
more time to optimise the code than CLR.

*** Why? What stops the C# compiler to take more time to optimize? Do you
think the C# compiler team is sleeping now?


Like this:

http://msdn.microsoft.com/msdnmag/is...5/default.aspx

"While the just-in-time (JIT) compiler today analyzes for optimizations at
run time, allowing the C++ compiler to optimize during the initial
compilation can still provide significant performance benefits (the C++
compiler has much more time to perform its analysis than does the JIT)."

*** The same goes for C# isn't it?

Willy.

[Olaf Baeyens]

> >> Managed C++/CLI producing 25% faster code than C#. Any resources that

prove this claim?
...
Mentioned in:

http://microsoft.sitestream.com/Tech...V333_Sutte.ppt http://www.accu.org/conference/prese..._(keynote).pdf

...
****
Ok, but this doesn't prove the claim, it's just the source of all claims.

I was there at teched and when asked about the 25% difference, the answer I
got was - if this was true, the C# compiler team would have done a lousy job :-).
Anyway, all benchmarks I have done indicate differences in performance in
between +5% and -5% (yes, sometimes C# is faster).
For real world applications the performance difference is neglectable, don't forget that the BCL is all written in C#, and the CLR just sits in top of
the same C runtime and Win32.
Don't get me wrong C++/CLI is a great language extension and C++ my language of choice, but execution speed is not the differentiator when comparing with other managed languages.

I don't know how they tested this, but I do not see any visible speed
difference between managed C++ and C#
I base this experience because I just porter 80% of my managed C++ code to
C# and I do not notice any difference.
This C++ code ported to C# is 'exactly' the same code that I compare with.
The biggest diference is that for managed structures I had to add 'new' for
C# where I did not need this for C++.
I assume in some parts I lose speed and in other parts I gain speed.

The biggest speed gain is in development. The build takes now seconds while
the C++ version takes minutes.
No more fighting with wierd compiler and linker errors, the C# underlines in
red and blue where I have to fix.
Commenting funtions is now actually fun. :-)
Intellisense is lightning fast.
And a far smaller destination dll. :-)

Don't worry, I still use unmanaged C++ for the really preformance critical
functionality. :-)

[Ioannis Vranos]

Carl Daniel [VC++ MVP] wrote:

Ioannis Vranos wrote:

I do not know much on the subject, but in.NET specifically, one may
create dlls and use them, with no recompilation needed.

Exactly - that's why I say it's a step in the right direction. I'm not sure
it's the complete answer, but it's better than #include.

Well each mechanism is different. The #include mechanism is for
compile-time source code inclusion, while the #using mechanism is for
precompiled library use in run time.

--
Ioannis Vranos

[Ioannis Vranos]

Olaf Baeyens wrote:

I don't know how they tested this, but I do not see any visible speed
difference between managed C++ and C#
I base this experience because I just porter 80% of my managed C++ code to
C# and I do not notice any difference.
This C++ code ported to C# is 'exactly' the same code that I compare with.
The biggest diference is that for managed structures I had to add 'new' for
C# where I did not need this for C++.
I assume in some parts I lose speed and in other parts I gain speed.

The biggest speed gain is in development. The build takes now seconds while
the C++ version takes minutes.
No more fighting with wierd compiler and linker errors, the C# underlines in
red and blue where I have to fix.
Commenting funtions is now actually fun. :-)
Intellisense is lightning fast.
And a far smaller destination dll. :-)

Don't worry, I still use unmanaged C++ for the really preformance critical
functionality. :-)

I guess the major difference will be in C++/CLI and VC++ 2005 and
afterwards.
An interesting article I came across yesterday:

http://blogs.msdn.com/branbray/archi.../07/51007.aspx

--
Ioannis Vranos