C# Performance

[Guest]

1. What work is in progress to bring C# performance closer to C++/CLI? Can we
expect C# to equal C++/CLI performance? If so when?

2. Also what work is in progress to improve MSIL/CLR/JIT performance in
general? As relases to the Framework e.g. 2.1, 2.2,.. are made do these
include performance imporovements?

 

[Nicholas Paldino [.NET/C# MVP]]

Greg,

That's a pretty broad question. There is no one answer which will cover
the whole thing. I don't think that there is a specific goal to bring
performance to the same level as unmanaged C++ (I think it's actually VERY
close in many scenarios already). I am sure there are performance
enhancements that are being done in general, but I haven't come across any
documentation stating specific areas that are currently being looked at.

If you are looking for performance numbers in a specific situation, then
you should wire up some tests which perform the same work, and then see if
the numbers suit your needs.

Hope this helps.

 

[Guest]

Greg,
I found this piece by Grimes enlightening.

http://www.grimes.demon.co.uk/dotnet/man_unman.htm

Peter

 

[Mike]

Greg,
I found this piece by Grimes enlightening.

http://www.grimes.demon.co.uk/dotnet/man_unman.htm

Pretty impressive. A home-brew benchmark I did a while ago showed C# (a
pre-release of 1.0) was about about 300% slower than C code for a similarly
intensive task. (Which was still plenty performant enough for me -- I was
expecting much worse.) The FFT may be limited by the FPU pipeline,
minimizing the difference between the languages. Also, there's no memory
(de)allocation or passing of data to/from managed and unmanaged APIs. Tasks
like this may indeed by JITed to efficient code, and most other programs on
the other end of the scale will spend time waiting for disks, networks,
users, etc. - so they'll run just as fast. The interesting class of
programs to test would be those that are both compute and memory intensive
but not I/O bound, such as state-space searches and the like.

m

 

[Guest]

http://msdn.microsoft.com/visualc/productinfo/features/default.aspx

The above link in the 3rd paragraph down, lists C++ compiler support for
optimized MSIL code generation as a C++ advantage.

 

[Guest]

Absolutely.

While Grimes's piece is well done, it is still a rather narrow comparison
compared to the number of possible scenarios that could be tested and
compared.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Willy Denoyette [MVP]]

| http://msdn.microsoft.com/visualc/productinfo/features/default.aspx
|
| The above link in the 3rd paragraph down, lists C++ compiler support for
| optimized MSIL code generation as a C++ advantage.
| --
| Greg McPherran
| www.McPherran.com
|

This is marketing, not reality. Nothing stops the C# team or the VB team to
apply the same kind of optimization techniques. Don't forget that 99% of the
framework classes are written in C#, why would they optimize C++ emitted
MSIL more than the library code used by the same kind of C++ applications?

Willy.

 

[James Park]

| http://msdn.microsoft.com/visualc/productinfo/features/default.aspx
|
| The above link in the 3rd paragraph down, lists C++ compiler support for
| optimized MSIL code generation as a C++ advantage.
| --
| Greg McPherran
| www.McPherran.com
|

This is marketing, not reality. Nothing stops the C# team or the VB team
to
apply the same kind of optimization techniques.

Maybe they don't have the experience?

http://channel9.msdn.com/ShowPost.aspx?PostID=152476

 

[Paul Kline]

Hi,

I am a developer for a private company that does a lot of number
crunching for mapping technology. We have done a lot of testing and
benchmarking of C# vs C++. Here is what it boils down to. A well
written and knowledgeable C++ & X86 Assembler code Application is
going to BARELY out run (mind you, you have to use the CPU Specific
instructions like SSE3, FSINCOS, etc) vs a well written C# application.
Most of the time, C# is going to out run by default ANY C++
application, performance wise. 2 reasons why, and there are many more
is How C# handles JIT and certain API calls. Without going to a lot
of details, C# does things underneath the things calling a built in
function These internal functions are written by microsoft in very
tight code. Also, if .NET detects certain CPU types it will use that
such instruction, example X86-32 bit vs 64 bit, something that C++ does
not do by default or dynamically. JIT compiles the code at runtime...
it doesn't interrupt the code. .NET was built differently than java's
bytecode in this aspect, it was built to compile the code, not
interpreter the code, which leads to a different mind set.


If you have performance questions or need help, you may feel free to
contact me via email.

Paul

 

[bughunter]

Another factor is managed code's extremely fast allocation of memory on
the heap, which basically involves moving the pointer that represents
the top of the heap. This is possible because objects on teh heap are
periodiacally re-packed, thus eliminating hte problem of memory
fragmentation.

Of course the heap compacting has it's own overhead but overall I would
say it is a net gain. I've been very happy with performance on my CPU
bound search project - SharpNEAT (http://sharpneat.sourceforge.net)

Regards,

Colin

P.S. I used nprof, another sourceforge project, to iron out performance
bottlenecks with considerable success!

 

[Nick Hounsome]

Hi,

I am a developer for a private company that does a lot of number crunching
for mapping technology. We have done a lot of testing and benchmarking
of C# vs C++. Here is what it boils down to. A well written and
knowledgeable C++ & X86 Assembler code Application is going to BARELY
out run (mind you, you have to use the CPU Specific instructions like
SSE3, FSINCOS, etc) vs a well written C# application. Most of the time, C#
is going to out run by default ANY C++ application, performance wise. 2
reasons why, and there are many more is How C# handles JIT and certain API
calls. Without going to a lot of details, C# does things underneath the
things calling a built in function These internal functions are written
by microsoft in very tight code. Also, if .NET detects certain CPU types
it will use that such instruction, example X86-32 bit vs 64 bit, something
that C++ does not do by default or dynamically. JIT compiles the code at
runtime... it doesn't interrupt the code. .NET was built differently
than java's bytecode in this aspect, it was built to compile the code, not
interpreter the code, which leads to a different mind set.


If you have performance questions or need help, you may feel free to
contact me via email.

Paul

I would take your comments more seriously if you hadn't completely overdone
it - there is no way that ANY bytecode app will EVER beat even a badly
written C++ app until it has been JIT compiled - this means that unless a
method is executed more than once it can only contribute negatively to the
comparison.

Long running apps - maybe.
One shot stuff - no chance.

 

[bughunter]

I would take your comments more seriously if you hadn't completely overdone
it - there is no way that ANY bytecode app will EVER beat even a badly
written C++ app until it has been JIT compiled -

I would fundamentally disagree with this. I've seen some pretty poor
code in my time that enters unnecessary loops, repeats whole chunks of
execution, etc. However I guess you mean is if you take any given
algorithm and implement it in C++ and C#. I have to say though that
experiments I have run gave very similar results for C++ and C#, C# was
seen to drop behind when I started using foreach loops (there is a bug
performance bug of sorts in .Net 1.x) or using generic container
classes wher eboxing was needed, etc. Also I don't think the Hashtable
implementation is optimal.

One shot stuff - no chance.

Yeh and this can cause a problem in some situations. E.g. I have a
syntax coloured text editor that causes a whole load of lexer and
parser routines to be jitted when the user hits a key for the first
time. The solutions there is to pre-compile (ngen) the code, and since
we have an installer we do this at install time.

Colin.

 

[Willy Denoyette [MVP]]

| | >
| > | > | http://msdn.microsoft.com/visualc/productinfo/features/default.aspx
| > |
| > | The above link in the 3rd paragraph down, lists C++ compiler support
for
| > | optimized MSIL code generation as a C++ advantage.
| > | --
| > | Greg McPherran
| > | www.McPherran.com
| > |
| >
| > This is marketing, not reality. Nothing stops the C# team or the VB team
| > to
| > apply the same kind of optimization techniques.
|
| Maybe they don't have the experience?
|
| http://channel9.msdn.com/ShowPost.aspx?PostID=152476
|
|

This is an interview with the same PM who is responsible for the above
article, he does a great job in promoting his product, that's all. Don't
forget that if C++/CLI does not attain it's critical mass in terms of
user/developers, the product is doomed to die, that's the way it is in this
business.
Talking about experience, IMO the C# team has more experience than the C++
team when it comes to MSIL optimization, but this isn't the point really.
The target is the JIT compiler, that's the place you can optimize the most
and rest assured, they know that pretty well.


Willy.

 

[Mike]

Yeh and this can cause a problem in some situations. E.g. I have a
syntax coloured text editor that causes a whole load of lexer and
parser routines to be jitted when the user hits a key for the first
time. The solutions there is to pre-compile (ngen) the code, and since
we have an installer we do this at install time.

Can't you just call the routine in a background thread during the loading
phase of the app, and have a wait in case it isn't done (or show an
hourglass if input is impossible) by the time the user needs it? -- this way
you get all the delayed JIT advantages and no install stuff. Maybe your
module takes longer than mine did - most of the time you couldn't even tell.
Just let you user type but don't start coloring until the parser is loaded.
(Also the module would need to be kosher being init'd from one thread and
called from another later.)

m

 

[bughunter]

Can't you just call the routine in a background thread during the loading
phase of the app, and have a wait in case it isn't done (or show an
hourglass if input is impossible) by the time the user needs it? -- this way
you get all the delayed JIT advantages and no install stuff. Maybe your
module takes longer than mine did - most of the time you couldn't even tell.
Just let you user type but don't start coloring until the parser is loaded.
(Also the module would need to be kosher being init'd from one thread and
called from another later.)

Hi, Yes but we also went through a phase of trying to make the
application load faster which lead to the 'ngen on install' approach.
This then has the side effect of solving the problem with the syntax
coluring delay - which was quite significant because there was a whole
parsers (in this case Ecmascript) worth of classes getting JITted. On
top end machine we may now get away with this but we have a minimum
spec to consider of something like an 800Mhz PIII.

Regards,

Colin.