Performance of managed (.Net and DirectX) code for games and other GPU/CPU intensive applications

I'm not enough of a graphics programming or managed code guru to speak authoritatively on this but here goes anyway....
It looks to me like the whole managed code (.Net, managed DirectX, etc.) trend is going the way of the assembler to compiled code experience (for those ancient enough to remember that) or how things have gone with Java (another interpreted language).   In short, eventually the newer and more productive at design/coding time technology comes close enough to run time performance of the older  technology for the newer to rise to dominance. 
So, in the case of Microsoft and the difference between Win32 C++ and .Net/DirectX/XNA C#, we see a repeat of what has happened with their technologies several times before.  When Windows first came out the performance compared to DOS was laughable (as was the original performance of managed DirectX) but there were productivity and other reasons to develop the Windows(tm) platform.  Eventually the gap narrowed, or people didn't care as CPUs got more powerful and they were whetted to the features of the new technology, and one technology replaced the other - in this case Windows over DOS.
Now trying to wring out more and more performance out of a compiler/interpreter/etc. isn't easy but the basic math is on the side of technology provider (i.e. Microsoft) in this case....as it was with SUN and IBM with Java.  It may be a hard problem but if they can find the wicked-smart computer scientist who can solve it then they put that in the next release or update to the product and about 10s of thousands of developers get the benefits.
This is what happened with managed DirectX.  At the 2002 GDC, Microsoft demo'd a very early beta of it and claimed (rightly so) that it would only support about 40% the frame-rate of Win32 C++....i.e. Win32 was over 200% faster.  Four years later, they can relatively fairly claim to have narrowed that gap from 200% to 10%....roughly....maybe 15-20% but still not 200%! 
One could also argue that CPU/GPU performance is increasingly less relevant as games and other applications are more highly connected across networks - saving 1/20 of a millisecond in GPU performance doesn't do much when you have to wait 60 milliseconds on a network packet.
Still, for hard-core off-line games and simulations there hasn't been much of a "hook" to get people into managed DirectX.  Managed DirectX makes it easier to integrate with .Net and that makes it easier to do some networking in your application but aside from some convenience in making a game easier to update, not much done with this so far.
XNA offer a couple of things that will "hook" developers/producers...as long as the CPU/GPU performance is tolerable....and a bit more than vanilla Managed Direct X did. 
First, the ability to go cross-platform between PC and the XBox.  For producers hoping to reach as large a market as possible (with as little work as possible), this is huge.  Sort of a large-scale example of "re-use". 
The other is that XNA is a piece of how developers will get access to the Live (as in XBox Live and now Windows Live) technology - new on Windows but established (and wildly popular) on XBox.  Again, for a producer trying to have as attractive a product as possible and reach as many customers as possible, this is a pretty big draw.
Maybe I am looking too much at the "soft" stuff but I see other problems as important as the performance:
A multi-window programming model.  The current trend in managed DirectX, and formalized in DirectX 9 for Vista and DirectX 10, is away from the full-screen experience and into windowed DirectX applications.  This was disruptive for DOS programmers moving to Windows and I suspect the same will take place in this transition.
A declarative programming model. Moving from procedures (in C or VB) to classes (in C++ or now C#) was hard enough...and many didn't do it very well.  The declarative model for WinFX, Avalon, XNA, etc. isn't going to be easy for lots of people either.
To get a "hands-on" feel for the differences (both at development and run-time), I recommend the following books:
.Net Game Programming with DirectX 9.0 by Labao and Hatton. I don't like that the examples are mostly Visual Basic and Visual Basic .Net but they do several side-by-side comparisons of the same project in both technologies.
Managed DirectX 9 - Graphics and Game Programming by Miller.  This is a SAMs book and I generally don't like those but this one is written by the development lead for the Managed DirectX API.  Starts off easy enough (if anything about this is "easy") but also covers advanced topics - e.g. I understand the HLSL in okay concept but still can't program it.
Professional WinFX (beta), WROX. Also covers WCF/Indigo - which is a functionally unrelated technology.  The Avalon/XAML examples give a pretty good idea of how the declarative model works.
XAML in a Nutshell. O'Reilly. Covers the XAML stuff that is in the WROX book but since it focuses only on this goes into more detail.
Warning! - Managed DirectX 9 is stable now so the examples you see in the book match what you will find on MSDN and how the SDK works pretty well.  WinFX, Avalon, XAML and XNA are still very much in transition.  Being able to run the examples in those books (or from examples on the web) depends very heavily on having the same Community Technology Preview ("CTP" a.k.a. "beta") - i.e. the same  CTP for Windows Presentation Framework - as described in the book in the book you are using or MSDN examples you are following.
- Brian

No comments: