From C++ to C# and back again....

[Aaron]

I taught myself C++ a while back, but never got to
involved in actually writing applications with it. I
actually spent the last 6 years working for numerous
internet web firms as well as doing a plethora of
freelance web development work. Lately I started learning
c#. The idea is to stop using coldfusion and switch to
writing c# using asp.net. The advantage I believe is that
I can develop websites and software that reuse code and
are tied together in a Solution. This idea is very
exciting to me.

One of my other passions and interests is game
development. I've looked around at a lot of different
websites and have read over and over again that although
game development with c# is possible; it's just not
pratical, due to peformance issues brought on by
using .net, etc.

It is my understanding, however, that as a .net
application runs the called functions are compiled to
native code through the JIT compiler. Only functions that
are called are compiled, but once compiled, are not
recompiled through the life of the program. In addition to
this, the compiled code is more effecient since it is
compiled specifically for the system and processor it is
running on. And typically speaking, as a .net program
runs; it gets faster and faster (obviously hitting a
plateau when all code is compiled).

If this is the case, wouldn't a game programmed
using .net, have better performance? Isn't it possible to
still use pieces of assembly code or otherwise unsafe code
for specific functions where performance is key?

I was looking at the Mangaged C++ port of the Quake II
engine the other day and was reading that "Running Quake
II.NET in the timedemo test indicates the managed version
performs about 85% as fast as the native version."
(http://www.vertigosoftware.com/Quake2.htm). The didn't do
much explaination as to why the managed version was
slower.

C# itself doesn't seem like it was meant for game
programming. Am I right? What advantages does the C++
language have over C# that makes it better for game
programming (as far as syntax goes, not performance)?

Thank you.

[Tad Marshall]

Your last sentence, that "You may find ... that the managed code works just
fine", is so true.

I just finished a program where I was doing processing on daily stock
prices, and had 30 years of data to process. I was afraid that this thing
would take days or weeks to do its job, but the managed code could run
through the entire 3.9 million records in about 15 minutes. Rewriting it
for greater speed would have been a waste of my time. Had it taken 15 hours
to do this work, I'd be rewriting it, but at 15 minutes per run it just
doesn't merit extra effort on my part.

It all depends on what you are doing. Managed .NET code is not necessarily
"slow" code relative to your needs, it all depends on what you are doing and
what your requirements are.

On a different part of the same project, I was writing code that hit the
same data over-and-over, and there was a lot of data to hit. In this case,
the key to speed was processing chunks of data that fit into the CPU cache.
When processing 30 MB of data, the speed was 8 loops per second, when
processing 600 KB of data the speed was 2000 loops per second. The extra
hit to read the data from disk in small chunks was trivial compared to the
speedup by getting all my data into the processor's 1 MB cache. A 20 hour
(projected) processing time was cut to 20 minutes. If you see actual
numbers and have a sense for what you are trying to do, you can sometimes
get improvements like this. The two hours of coding I did to rewrite my
algorithm were paid back in my first run of the data.

I'll add one more thought ... the very biggest returns to optimization come
from finding something that you don't actually have to do, and not doing it.
Making "uselessRepetit iveRoutine()" run at maximum speed is no where near as
effective as not calling it in the first place. Every now and then, this
tip makes all the difference.

Tad

"John Puopolo" <jo**********@f astsearch.com.n ospam> wrote in message
news:eG******** ******@TK2MSFTN GP12.phx.gbl...

Hi...

I think the former would work the best. In my experience (15 yrs)
developing software, one tenet has worked well for me... "make it work -
then make it work fast."

It is very difficult if near impossible to determine where your code is
spending its time -- so the only way to know where to optimize it to write
the code (in C#), profile it, then re-write the most-used routines in
C/C++
or assembly to get the speed that you need.

You may find, however, that the managed code works just fine and that you
do
not need to use unmanaged code at all.

John Puopolo