473,320 Members | 1,988 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

C# Performance

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?

--
Greg McPherran
www.McPherran.com
Feb 2 '06 #1
14 2346
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Greg" <gm@mcpherran.com> wrote in message
news:0B**********************************@microsof t.com...
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?

--
Greg McPherran
www.McPherran.com

Feb 2 '06 #2
Greg,
I found this piece by Grimes enlightening.

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

Peter

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


"Greg" wrote:
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?

--
Greg McPherran
www.McPherran.com

Feb 2 '06 #3

"Peter Bromberg [C# MVP]" <pb*******@yahoo.nospammin.com> wrote in message
news:DA**********************************@microsof t.com...
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

Peter

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


"Greg" wrote:
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?

--
Greg McPherran
www.McPherran.com

Feb 3 '06 #4
http://msdn.microsoft.com/visualc/pr...s/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

Feb 3 '06 #5
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


"Mike" wrote:

"Peter Bromberg [C# MVP]" <pb*******@yahoo.nospammin.com> wrote in message
news:DA**********************************@microsof t.com...
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

Peter

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


"Greg" wrote:
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?

--
Greg McPherran
www.McPherran.com


Feb 3 '06 #6

"Greg" <gm@mcpherran.com> wrote in message
news:8F**********************************@microsof t.com...
| http://msdn.microsoft.com/visualc/pr...s/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.
Feb 3 '06 #7
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:eC**************@TK2MSFTNGP11.phx.gbl...

"Greg" <gm@mcpherran.com> wrote in message
news:8F**********************************@microsof t.com...
| http://msdn.microsoft.com/visualc/pr...s/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
Feb 3 '06 #8
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
Willy Denoyette [MVP] wrote:
"Greg" <gm@mcpherran.com> wrote in message
news:8F**********************************@microsof t.com...
| http://msdn.microsoft.com/visualc/pr...s/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.


Feb 3 '06 #9
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!

Feb 3 '06 #10

"Paul Kline" <pk********@msn.com> wrote in message
news:ew**************@TK2MSFTNGP09.phx.gbl...
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.

Feb 3 '06 #11

Nick Hounsome wrote:
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.

Feb 3 '06 #12

"James Park" <so*****@hotmail.com> wrote in message
news:OD**************@TK2MSFTNGP12.phx.gbl...
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:eC**************@TK2MSFTNGP11.phx.gbl...
| >
| > "Greg" <gm@mcpherran.com> wrote in message
| > news:8F**********************************@microsof t.com...
| > | http://msdn.microsoft.com/visualc/pr...s/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.
Feb 3 '06 #13

<bu*******@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
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
Feb 3 '06 #14

Mike wrote:
<bu*******@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
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.)


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.

Feb 6 '06 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

25
by: Brian Patterson | last post by:
I have noticed in the book of words that hasattr works by calling getattr and raising an exception if no such attribute exists. If I need the value in any case, am I better off using getattr...
12
by: Fred | last post by:
Has anyone a link or any information comparing c and c++ as far as execution speed is concerned? Signal Processing algorithms would be welcome... Thanks Fred
12
by: serge | last post by:
I have an SP that is big, huge, 700-800 lines. I am not an expert but I need to figure out every possible way that I can improve the performance speed of this SP. In the next couple of weeks I...
6
by: teedilo | last post by:
We have an application with a SQL Server 2000 back end that is fairly database intensive -- lots of fairly frequent queries, inserts, updates -- the gamut. The application does not make use of...
5
by: Scott | last post by:
I have a customer that had developed an Access97 application to track their business information. The application grew significantly and they used the Upsizing Wizard to move the tables to SQL...
115
by: Mark Shelor | last post by:
I've encountered a troublesome inconsistency in the C-language Perl extension I've written for CPAN (Digest::SHA). The problem involves the use of a static array within a performance-critical...
13
by: bjarne | last post by:
Willy Denoyette wrote; > ... it > was not the intention of StrousTrup to the achieve the level of efficiency > of C when he invented C++, ... Ahmmm. It was my aim to match the performance...
13
by: Bern McCarty | last post by:
I have run an experiment to try to learn some things about floating point performance in managed C++. I am using Visual Studio 2003. I was hoping to get a feel for whether or not it would make...
7
by: Michael D. Ober | last post by:
When calling Enqueue, the internal array may need to be reallocated. My question is by how much? In the old MFC array classes, you could tell MFC how many additional elements to add to the array...
1
by: jvn | last post by:
I am experiencing a particular problem with performance counters. I have created a set of classes, that uses System.Diagnostics.PerformanceCounter to increment custom performance counters (using...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.