By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,017 Members | 1,004 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,017 IT Pros & Developers. It's quick & easy.

Improving performance C++/C#

P: n/a
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?
Nov 17 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Hi,

Managed C++ and C# SHOULD theoretically compile to the same (or equivalent)
MSIL, so you should see no speed differences. In both cases, optimization is
performed by the JIT compiler at runtime. However, I'm not entirely sure as
to the relationship with VC++'s compiler optimization settings. Certainly
for unmanaged code they can make an enormous difference. They could have an
effect on managed code, but I don't know. If you're performing serious
number crunching in the unmanaged C++ you may find a performance hit if you
convert to C#. Having said that, coded well, performance problems should be
neglible. From my own experience, the difference between a debug build (no
optimization) and a release build (C++ compiler and linker optimization and
JIT optimization) there is a difference, but it tends to be noticeable in
the areas where there's processor intensive work going on (which is done by
a mixture of managed and unmanaged functions).

I suppose it depends on your app - is ease of development more valuable to
you than squeezing out performance? You'll never really know until you've
tried the C# ports, I guess. Maybe someone more knowledgeable than myself
can inform you (and me!) what effect the C++ compiler optimizations do in
combination with the JIT compiler.

Steve

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:41**********************@news.skynet.be...
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?

Nov 17 '05 #2

P: n/a
Steve McLellan wrote:
Hi,

Managed C++ and C# SHOULD theoretically compile to the same (or equivalent)
MSIL, so you should see no speed differences. In both cases, optimization is
performed by the JIT compiler at runtime. However, I'm not entirely sure as
to the relationship with VC++'s compiler optimization settings. Certainly
for unmanaged code they can make an enormous difference. They could have an
effect on managed code, but I don't know. If you're performing serious
number crunching in the unmanaged C++ you may find a performance hit if you
convert to C#. Having said that, coded well, performance problems should be
neglible. From my own experience, the difference between a debug build (no
optimization) and a release build (C++ compiler and linker optimization and
JIT optimization) there is a difference, but it tends to be noticeable in
the areas where there's processor intensive work going on (which is done by
a mixture of managed and unmanaged functions).

I suppose it depends on your app - is ease of development more valuable to
you than squeezing out performance? You'll never really know until you've
tried the C# ports, I guess. Maybe someone more knowledgeable than myself
can inform you (and me!) what effect the C++ compiler optimizations do in
combination with the JIT compiler.

VC++ is and will even more in the future, produce more optimised code
than VC#.

Typically 25% faster code than C#. Upcoming optimisations available only
for C++ including PGO and OpenMP extensions etc support have serious
impact for critical applications.
Also provided C#/CLI deficiencies in comparison to the upcoming C++/CLI,
I cannot understand why one should move from C++ to C#.

Some references:
C++/CLI (vs C#/CLI)

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

VC++ oriented optimisations:

http://msdn.microsoft.com/msdntv/epi...G/manifest.xml
http://msdn.microsoft.com/visualc/de...timization.asp

--
Ioannis Vranos
Nov 17 '05 #3

P: n/a
"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:O7**************@TK2MSFTNGP15.phx.gbl...
Steve McLellan wrote:
Hi,

VC++ is and will even more in the future, produce more optimised code
than VC#.

Typically 25% faster code than C#. Upcoming optimisations available only
for C++ including PGO and OpenMP extensions etc support have serious
impact for critical applications.
Also provided C#/CLI deficiencies in comparison to the upcoming C++/CLI,
I cannot understand why one should move from C++ to C#.


Hi,

I remember arguing about this before so I won't rehash it :-) That info's
good to know - it means that the tradeoff between C++ and C# (execution
speed rather than faster (or simpler) development) will probably still
remain. I didn't know that PGO was only for C++, that's interesting to note.

Thanks,

Steve
Nov 17 '05 #4

P: n/a
PGO is for native C++ only.

Managed C++/CLI producing 25% faster code than C#. Any resources that prove
this claim?
As far I see the differences are neglectable ,which is quite normal as both
generate almost the same IL that uses the same JIT backend.

Willy.

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:O7**************@TK2MSFTNGP15.phx.gbl...
Steve McLellan wrote:
Hi,

Managed C++ and C# SHOULD theoretically compile to the same (or
equivalent)
MSIL, so you should see no speed differences. In both cases, optimization
is
performed by the JIT compiler at runtime. However, I'm not entirely sure
as
to the relationship with VC++'s compiler optimization settings. Certainly
for unmanaged code they can make an enormous difference. They could have
an
effect on managed code, but I don't know. If you're performing serious
number crunching in the unmanaged C++ you may find a performance hit if
you
convert to C#. Having said that, coded well, performance problems should
be
neglible. From my own experience, the difference between a debug build
(no
optimization) and a release build (C++ compiler and linker optimization
and
JIT optimization) there is a difference, but it tends to be noticeable in
the areas where there's processor intensive work going on (which is done
by
a mixture of managed and unmanaged functions).

I suppose it depends on your app - is ease of development more valuable
to
you than squeezing out performance? You'll never really know until you've
tried the C# ports, I guess. Maybe someone more knowledgeable than myself
can inform you (and me!) what effect the C++ compiler optimizations do in
combination with the JIT compiler.

VC++ is and will even more in the future, produce more optimised code than
VC#.

Typically 25% faster code than C#. Upcoming optimisations available only
for C++ including PGO and OpenMP extensions etc support have serious
impact for critical applications.
Also provided C#/CLI deficiencies in comparison to the upcoming C++/CLI, I
cannot understand why one should move from C++ to C#.

Some references:
C++/CLI (vs C#/CLI)

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

VC++ oriented optimisations:

http://msdn.microsoft.com/msdntv/epi...G/manifest.xml
http://msdn.microsoft.com/visualc/de...timization.asp

--
Ioannis Vranos

Nov 17 '05 #5

P: n/a
Steve McLellan wrote:
Hi,

I remember arguing about this before so I won't rehash it :-) That info's
good to know - it means that the tradeoff between C++ and C# (execution
speed rather than faster (or simpler) development) will probably still
remain. I didn't know that PGO was only for C++, that's interesting to note.


Faster development than what? Both have the exactly the same RAD and APIs.

--
Ioannis Vranos
Nov 17 '05 #6

P: n/a
I was refering to managed C++!
VC++ is and will even more in the future, produce more optimised code
than VC#.
This is what I don't know. Hard to predict the future.
Managed C++ and C# come close together in IL code.
Typically 25% faster code than C#.
My tests so far are closer to 10% between managed and unmanaged. But I think
it depends what you do.
I cannot understand why one should move from C++ to C#.

The biggest reason is compile time. which reduces dramatic
The second biggest is the syntax has been cleaned up, and is more intuitive,
so less likely to make errors, that you discover during compiling.
Third biggest reason is that no strange compiler and linker errors that
keeps you busy for days just to discover that an ";" has been misplaced.

For performance critical parts I still use unmanaged C++ so I am not running
away from C++, I just want to add the nice features of C# to speed up
development.

The biggest problem I always faced with C++ is these include paths,
cryptical compiler errors and the dreaded linker errors.
This is something I do not have in C#, so I am far more productive.

I am suprised that managed C++ would be faster than C# because C# does not
have to take unmanaged code into account within the same dll, and could
produce faster and compacter code.
I always assumed that there is some overhead in managed C++. Also the C#
compiler is provided with the .NET framework, so always optimized when you
upgrade to the newest .NET.

But this is my viewpoint.

I have started to port some small classes, but very intensively used to C#
and it seems not performance difference so far.
Nov 17 '05 #7

P: n/a
> Faster development than what? Both have the exactly the same RAD and APIs.

Compiles much faster. :-)
This compile time is what slows me down because of the huge number of lines
in my class library.
Nov 17 '05 #8

P: n/a
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.
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.
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)."

--
Ioannis Vranos
Nov 17 '05 #9

P: n/a
Olaf Baeyens wrote:
My tests so far are closer to 10% between managed and unmanaged. But I think
it depends what you do.

I am talking only about pure IL code.
And since on the subject let me give some examples of language strength:


Can you do this kind of thing in C# at *compile time*, producing 100%
verifiable code?
//A template function adding two objects
template <class T>
inline T Add(const T %a, const T %b)
{
return a+b;
}

value class someclass
{
int x;
};


int main()
{
int x = 7, y = 8;

int r = Add(x,y);
}
C:\c>cl /clr:safe temp.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40809
for Microsoft (R) .NET Framework version 2.00.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.40809
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj

C:\c>

What about this:
ref class ReferenceType
{
int i;

public:
ReferenceType():i(1) {}
ReferenceType(const ReferenceType %x) { i=x.i; }

void print() { System::Console::WriteLine(i); }

};
template <class T>
void display(T x)
{
x.print();
}

int main()
{
// Object with stack semantics - Deterministic destruction
// at the end of its scope
ReferenceType obj;

display(obj);
// Object in the managed heap
ReferenceType ^hobj= gcnew ReferenceType;

display(*hobj);
// Deterministic destruction
delete hobj;
ReferenceType ^hobj2= gcnew ReferenceType;

display(*hobj2);

// Not destroying hobj2, let it be finalised
}

C:\c>cl /clr:safe temp.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40809
for Microsoft (R) .NET Framework version 2.00.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.40809
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj

C:\c>temp
1
1
1

C:\c>
That is 100% verifiable code.

--
Ioannis Vranos
Nov 17 '05 #10

P: n/a
Olaf Baeyens wrote:
Compiles much faster. :-)
This compile time is what slows me down because of the huge number of lines
in my class library.


Yes VC++ compilation may be slower (since) but more compile time
optimisations take place.

--
Ioannis Vranos
Nov 17 '05 #11

P: n/a
> > My tests so far are closer to 10% between managed and unmanaged. But I
think
it depends what you do.


I am talking only about pure IL code.

And since on the subject let me give some examples of language strength:

Can you do this kind of thing in C# at *compile time*, producing 100%
verifiable code?


Very nice, but now is the question do we really need this?
The part that I am porting is not very critical in speed for the end-user.
But it helps me compiling faster, reducing development time.
Nov 17 '05 #12

P: n/a
Olaf Baeyens wrote:
My tests so far are closer to 10% between managed and unmanaged. But I
think
it depends what you do.
I am talking only about pure IL code.

And since on the subject let me give some examples of language strength:

Can you do this kind of thing in C# at *compile time*, producing 100%
verifiable code?

Very nice, but now is the question do we really need this?

Yes. Especially to write compile-time optimal generic facilities to be
placed in libraries. :-)

Generics will be run-time and more limiting.


The part that I am porting is not very critical in speed for the end-user.
But it helps me compiling faster, reducing development time.

Anyway. :-)

--
Ioannis Vranos
Nov 17 '05 #13

P: n/a
> > Very nice, but now is the question do we really need this?

Yes. Especially to write compile-time optimal generic facilities to be
placed in libraries. :-)

Generics will be run-time and more limiting.


Don't worry, I still use C++. ;-)
It is only parts of the code that gets ported.

I am busy right now doing the (partial) port, and I already feel it that I
can compile faster.
With no noticible slow down of the program.

I am wondering how long C++ will stay here since all languages tend to move
to .NET framework so the speed will become more and more the same.
Sooner or later one .NET language will use components from other .NET
languages and we will have one big pool with components.

I believe that unmanaged C++ will be phased out just like assembler did at
some future point of time.
Assembler still exists, just integrated into C++.
Nov 17 '05 #14

P: n/a
Olaf Baeyens wrote:
I am wondering how long C++ will stay here since all languages tend to move
to .NET framework so the speed will become more and more the same.
Sooner or later one .NET language will use components from other .NET
languages and we will have one big pool with components.

I believe that unmanaged C++ will be phased out just like assembler did at
some future point of time.
Assembler still exists, just integrated into C++.

Again, previously I was not talking about native C++ but for pure
managed CLI (.NET) code.

Native code will always be around.
In addition, in Longhorn edition of VS (code named Orcas), these 4
things will be possible:
CLI types in managed heap/stack (available today / VC++ 2005)

Native types in unmanaged heap/stack (available today)

CLI types in *unmanaged heap*.

Native types in *managed heap*.

--
Ioannis Vranos
Nov 17 '05 #15

P: n/a
Olaf Baeyens wrote:
I am busy right now doing the (partial) port, and I already feel it
that I can compile faster.


My $0.02 worth:

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).

In the end, it's hard to say which compiler will slow you down more.

-cd
Nov 17 '05 #16

P: n/a
Carl,
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.
--
Tomas Restrepo
to****@mvps.org
Nov 17 '05 #17

P: n/a
> > 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.
Nov 17 '05 #18

P: n/a
Olaf Baeyens wrote:
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.
Changing a widely included header does cause great pain. Of course, a great
deal (a very great deal actually) of that pain can be mitigated by proper
construction and use of header files to minimize coupling and dependencies
(read John Lackos - "Large Scale C++ Development" for lots of
recommendations). Nonetheless, when you have to change something at the
lowest level, it hurts - no denying it.
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.


Some day. Maybe. Unfortunately, compatibility with C has us stuck with a
primitive text splicing mechanism instead of a real module concept.
Personally, I think this is an area where a vendor, such as Microsoft, needs
to step in and build a well thought-out module mechanism that can replace
the preprocessor for most (but probably not all) use. Only then is there a
real chance that the C++ community at large will finally move on this issue.
It's been discussed for over a decade now and nothing's happened.

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

-cd
Nov 17 '05 #19

P: n/a
Carl Daniel [VC++ MVP] wrote:
Some day. Maybe. Unfortunately, compatibility with C has us stuck with a
primitive text splicing mechanism instead of a real module concept.
Personally, I think this is an area where a vendor, such as Microsoft, needs
to step in and build a well thought-out module mechanism that can replace
the preprocessor for most (but probably not all) use. Only then is there a
real chance that the C++ community at large will finally move on this issue.
It's been discussed for over a decade now and nothing's happened.

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

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

--
Ioannis Vranos
Nov 17 '05 #20

P: n/a
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
Nov 17 '05 #21

P: n/a
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;
Nov 17 '05 #22

P: n/a
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
Nov 17 '05 #23

P: n/a
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)necessitate 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
Nov 17 '05 #24

P: n/a
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)necessitate 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
Nov 17 '05 #25

P: n/a
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
Nov 17 '05 #26

P: n/a
See inline ***.

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:%2****************@TK2MSFTNGP12.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.
Nov 17 '05 #27

P: n/a
> >> 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. :-)
Nov 17 '05 #28

P: n/a
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
Nov 17 '05 #29

P: n/a
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
Nov 17 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.