VS.NET Perfomance and speed question ( Comparing with C++ Apps)

  • Thread starter Thread starter HerrLucifer
  • Start date Start date
H

HerrLucifer

I am each day becoming more and more addicted to the new .Net
framework because of its cool RAD facilities. However, performance and
speed is extremely important for my application development. I have
done many various tests to compare the performance speed of
applications written in C++ 6.0 V.S. the same ones in VB.Net or
VC#.Net . The result were quiet the same( i am not sure if i have go
the right path!). But I know C++ exe files use "KERNEL32.DLL" directly
while .Net exe files are first taken in by "MSCOREE.DLL", which in
itself depends on "KERNEL32.DLL and "ADVAPI32.DLL", and then they are
executed.

I need you expert guys out there help me more on this issue.
eg: Is .Net really suitable for making 3D games? or such applications
which really
consume CPUs.
(Also, comparing applications load time, I think C++ ones are always
the winners)
 
managed code would be the wrong answer for a challenge like writing a chess
engine or doing heavy graphics work.
 
Why? Then how is the world going to be all in .Net in future? Won't
microsoft solve this issue?
 
I disagree. Unlike Java, .NET does not require a Virtual Machine to run.
..NET uses JIT Compilation -- you'll hardly notice a difference.

Heavy graphics work can utilize DirectX in .NET using the DX SDK, which
would allow it to be as fast as C++.
 
When you get into code that you are actually considerring writing inline
assembler for because your C compiler generates slow code ... .NET is not
the right choice. these are specialized examples where speed is the only
concern ...
 
You can also have assembler code in managed c++ applications,
so called mixed executables.
Or you can have the code externally in native compiled Dlls, which
are called from managed code. E.g. the application written in
C# calling code written in managed C++ or native C++.

You´ll have the advantages from both worlds.
Rapid prototyping and fast code.

It´s also possible to have fast games written in managed c++
Have a look at the following article:

http://www.codeproject.com/managedcpp/quake2.asp

Andre
 
Alex Papadimoulis said:
I disagree. Unlike Java, .NET does not require a Virtual Machine to run.
.NET uses JIT Compilation -- you'll hardly notice a difference.
Click to expand...

The CLR *is* a virtual machine, really. It's not like Java doesn't get
JIT compiled on pretty much every JVM these days.
 
HerrLucifer said:
I am each day becoming more and more addicted to the new .Net
framework because of its cool RAD facilities. However, performance and
speed is extremely important for my application development. I have
done many various tests to compare the performance speed of
applications written in C++ 6.0 V.S. the same ones in VB.Net or
VC#.Net . The result were quiet the same( i am not sure if i have go
the right path!). But I know C++ exe files use "KERNEL32.DLL" directly
while .Net exe files are first taken in by "MSCOREE.DLL", which in
itself depends on "KERNEL32.DLL and "ADVAPI32.DLL", and then they are
executed.

I need you expert guys out there help me more on this issue.
eg: Is .Net really suitable for making 3D games? or such applications
which really consume CPUs.
(Also, comparing applications load time, I think C++ ones are always
the winners)
Click to expand...

The problem with using managed code for games is garbage collection.
While in most apps it doesn't matter if you have a 0.05s pause (to
pluck a number from the air at random) every so often, games reviewers
would absolutely murder a game which did that.

Now, that may make it inappropriate for some games but not others - and
it *doesn't* make it inappropriate for other CPU-intensive
applications.
 
I may be wrong but I thought i heard that quake or doom (i am not into games) was rewritten in managed code as an experiment(!) and that it ran approx 90% the speed of the original.

guy
 
gc can have different implementations in any case - consider the server and
client versions already in existence
 
Jason said:
gc can have different implementations in any case - consider the server
and
client versions already in existence
Click to expand...

Certainly. And it would be nice to see a realtime type gc at some point. A
game would probably be easily written with a gc which can only execute when
called upon or is given time constraints. Its pretty much the same approach
as a realtime system would need. However, no such GC exists currently and
because of the fragile nature of a system running on such a runtime and
garabage collector, you are much less likely to retain the portability one
would want.
 
This is exactly what we do; we've got some really heavy number crunching in
old skool C++, and everything else (the UI and file IO) in managed C++. It
works well, as long as you're aware where you can get bottlenecks (and you
have a decent profiler).

Steve
 
The System performance degrades alot when the VS.NET2005 is opened. BUt it has got a lot of cool appearance
 
This is not entirely true... There are 2 types of directX programming that can be done. DirectX retained mode and Intermediate mode. The C# directX sdk is based on the Intermediate mode programming and thus gives more high level control over the API. This also degrades performance compared to standard C++ applications running in DirectX Retained mode. Unless there is some heavy modification done to the CLR, C# will never be able to compare in speed to DirectX apps written in Retained mode...
 
This is not entirely true... There are 2 types of directX programming that can be done. DirectX
Click to expand...
retained mode and Intermediate mode. The C# directX sdk is based on the Intermediate mode
programming and thus gives more high level control over the API. This also degrades performance
compared to standard C++ applications running in DirectX Retained mode. Unless there is some heavy
modification done to the CLR, C# will never be able to compare in speed to DirectX apps written in
Retained mode...

I think you have this the wrong way round. Retained mode was a set of Direct3D wrappers that run
slowly, but were easier to use for introductions to the API; Immediate mode meant actually using the
core API. However this is all very old stuff since Retained mode was reduced to an appendix in the
DX7 SDK 5 years ago and removed entirely with DX8. I admit I haven't used C# for D3D programming,
but are you sure it's using the higher-level-but-slower Retained mode? I'd be very surprised.

Andrew
 
Andrew said:
retained mode and Intermediate mode. The C# directX sdk is based on the Intermediate mode
programming and thus gives more high level control over the API. This also degrades performance
compared to standard C++ applications running in DirectX Retained mode. Unless there is some heavy
modification done to the CLR, C# will never be able to compare in speed to DirectX apps written in
Retained mode...

I think you have this the wrong way round. Retained mode was a set of Direct3D wrappers that run
slowly, but were easier to use for introductions to the API; Immediate mode meant actually using the
core API. However this is all very old stuff since Retained mode was reduced to an appendix in the
DX7 SDK 5 years ago and removed entirely with DX8. I admit I haven't used C# for D3D programming,
but are you sure it's using the higher-level-but-slower Retained mode? I'd be very surprised.

Andrew
Click to expand...

I am quite new to C# and the whole .NET sceanario, but i currently have
the DirectX SDK and am using it for MDX. Im pretty sure its itermediate
mode, requires users to perform matrix manipulations manually etc. So
would this make it as fast as the C++ version?
 
Oliver "aCiD2" Charles said:
...
I am quite new to C# and the whole .NET sceanario, but i currently have
the DirectX SDK and am using it for MDX. Im pretty sure its itermediate
mode, requires users to perform matrix manipulations manually etc. So
would this make it as fast as the C++ version?
Click to expand...

First: Don't trust anyone but your own benchmark!
That said: managed code will get compiled to native code too, only later.
Why do you think it should run slower after that?
The only way to really make it faster would probably be to use
processor-specific SIMD instructions, but AFAIK you can't do that in C++
directly, either.

BTW: I'm not a game programmer, but I thought one of the major advances in
the last few years was that many matrix operations are done in the GPU now?
(T&L, Vertex Shaders...)

Niki
 
Back
Top