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?

[Steve McLellan]

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**********@s kyscan.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?

[Ioannis Vranos]

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

[Steve McLellan]

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message
news:O7******** ******@TK2MSFTN GP15.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

[Willy Denoyette [MVP]]

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******** ******@TK2MSFTN GP15.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

[Ioannis Vranos]

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

[Olaf Baeyens]

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.

[Olaf Baeyens]

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

[Ioannis Vranos]

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

[Ioannis Vranos]

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(c onst 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