speed of c# code in general compared to compiled native code

[Peted]

hi,

im wondering if there is a definitve answer to this.

If you build a winforms/wpf application in vs2008, when you have
compiled and run the app, does it run as fast (in general) as if you
used something like a xenocode compiler to convert to native code.

I hear things like the xenocode option only makes a minor speed
improvement in startup.

So what if you wanted to write a game in c# using the directx sdk.
Would you be better of using c++.

How can one know if there is a performance impediment in the whole
dotnet bytecode to native realtime conversion

thanks for any info

Peted

[Peter Duniho]

On Thu, 12 Jun 2008 18:52:46 -0700, <Petedwrote:

im wondering if there is a definitve answer to this.

It's impossible for there to be one, as each program has different
performance requirements and characteristics.

If you build a winforms/wpf application in vs2008, when you have
compiled and run the app, does it run as fast (in general) as if you
used something like a xenocode compiler to convert to native code.

"In general", I have found little to no difference in execution speed.
Where there does happen to be a speed difference, it is almost always
related to my use of .NET, not the compiled C# code itself.

I hear things like the xenocode option only makes a minor speed
improvement in startup.

A quick look at the Xenocode web site suggests that it's doing a lot more
than just precompiling the application. But yes, inasmuch as it avoids
the JIT compiler having to compile the IL of your application, I can see
how startup would be faster. I don't think you'd use Xenocode for just
that reason though. It looks like a pretty heavy-weight approach.

So what if you wanted to write a game in c# using the directx sdk.
Would you be better of using c++.

I doubt it. At best, you might write your game physics and AI in C++, but
frankly I think any speed improvement, if any, would be negligible.

How can one know if there is a performance impediment in the whole
dotnet bytecode to native realtime conversion

Write both and compare it. Some algorithms will see a difference, some
will not. It's very difficult to know in advance which are which.

Pete

[Cowboy \(Gregory A. Beamer\)]

"Peted" wrote in message news:uv********************************@4ax.com...

hi,

im wondering if there is a definitve answer to this.

I am tracking with Peter on this one, as there are some cases where C++
smokes C# and a few where C# smokes C++. In general, both are fairly
equivalent. And, in those cases where you need something native, you can
always write in C++ for the algorithms that need that tweak.

If you build a winforms/wpf application in vs2008, when you have
compiled and run the app, does it run as fast (in general) as if you
used something like a xenocode compiler to convert to native code.

I would say yes, as there is generally not a lot of difference in speed of
UI, business logic and data access. When you move to serious graphical
calculations, as you suggest later, you might see a difference. I am not
sure I would use Xenocode to do this; it would probably be better to bite
the bullet and do it all in C++.

I hear things like the xenocode option only makes a minor speed
improvement in startup.

Not sure, but the startup time is definitely less if you do not have to JIT.

So what if you wanted to write a game in c# using the directx sdk.
Would you be better of using c++.

I would disagree a bit with Peter on this, as it would probably depend on
the game. Overall, since the majority of your graphics code is in the
DirectX libraries, there should not be a lot of difference, but you might
end up with a difference with certain types of game physics.

How can one know if there is a performance impediment in the whole
dotnet bytecode to native realtime conversion

I have found none, but I have not written a lot of gaming code. There are a
few cycles each time you marshall from managed to unmanaged, but this would
not be a major impediment unless you were constantly marshalling, as in a
very large loop. It would be easy enough to set up a simple application that
hits some DirectX bits and profile it both in native and managed. I believe
you will find that the calls add a few microseconds to the time, which is
neglegible in most cases.

That being said, I not sure I would write a game like Quake 4 in C#. ;-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Peted wrote:

If you build a winforms/wpf application in vs2008, when you have
compiled and run the app, does it run as fast (in general) as if you
used something like a xenocode compiler to convert to native code.

Generally there is little difference. A tool like xenocode might do some
tricks to speed up the code, but on the other hand the JIT can
potentially produce code that is optimised for the specific processor it
is running on. Also, the JIT is getting better and better, so your .NET
code will get faster with each new version of the framework.

I hear things like the xenocode option only makes a minor speed
improvement in startup.

The shorter startup time is the most noticable difference. Other
differences are much more subtle, and may also vary from one system to
another.

--
Göran Andersson
_____
http://www.guffa.com

[Ben Voigt [C++ MVP]]

>So what if you wanted to write a game in c# using the directx sdk.

>Would you be better of using c++.

I doubt it. At best, you might write your game physics and AI in
C++, but frankly I think any speed improvement, if any, would be
negligible.

That's exactly what I wouldn't expect to help. The JIT is pretty decent at
optimizing loops and calculations. It's calls to external libraries (like
DirectX, which definitely is a native component) where you get hurt,
especially if you forget to turn off security checks.