IMO, selecting unmanaged code only for the sake of performance isn't a wise decision for many reasons:
1. As an independent/hobbyist, you're not going to reach your CPU limits anyway in either.
2. If you know what you're doing with managed code, you can easily get it to perform nearly as unmanaged. Saruman, who does commercial C# game development, will hopefully chime in with a long, tasty and insightful post about this [grin]

Quote:I am curious about what kind of an impact JIT compiled code has on cache performance.

If you're worried about JIT, you can always use ngen to generate a native image on deployment.

I've been programming in Managed DirectX for a few months now and I am quite pleased with the results I got in such a short time period. The thing that always held me back from 3D programming was C++. I did some work on various tools in C++, but I never felt quite comfortable with it. Stroustrup's book didn't help at all there, especially the chapter about the calculator gave me the creeps ;)

From a biased -former Java evangelist- point of view, I'd advise you to go with Managed DirectX. Sure, there are some drawbacks and pitfalls you'll have to take into account, but writing C# code is just way easier than tinkering in C++, especially for beginners. Managed DirectX is nearly as powerful as its unmanaged equivalent, without having to worry about daunting (well, at least for me :) language constructs. I'm no expert on Managed DX, but here are the pitfalls I had when starting out with it. If you decide to go with MDX, they may prove a useful read for you.


1. Lacking sample code

At first this isn't much a problem, but when you get the basics working and you start looking for fancier results, the lack of sample code will come back to haunt you.

Shadows, glow, particle systems, clouds, water, whatever you are looking for, chances are there are tons of samples available in C++, but none in C#. If you want any of these effects, you'll probably have to translate C++ samples to Managed DirectX, which can be a lot of work and daunting. Especially for beginners like me, who are typically the ones that need the samples anyway.

2. Implicit memory management

Just because you don't have to worry about memory management in C# doesn't mean you're home free. In fact, handling memory is probably the biggest adjustment you'll have to make to your coding style when you are used to Java or plain C# application programming.

You'll have to keep track of which resources you loaded into video memory, dispose of them when the device is lost and recreate them when the device is reset. For a C++ programmer this is nothing fancy, but it takes some getting used to when you've relied on the garbage collector for years :)

3. Documentation, or lack thereof

The managed API is sorely lacking documentation. It has improved somewhat with the Summer 2005 release, but it is by no means complete. At times you'll have to rely on instinct to find the right property to set, the right renderstate to enable or the correct event to hook. Sometimes it pays off to figure out the C++ equivalent of a piece of code and check out the docs on that.


All in all, Managed DirectX is still worth the effort. Over the few months I've been using it, more and more samples have become available and understanding the C++ samples gets easier when you get to understand MDX better, since they essentially use the same API. If you're an absolute beginner with 3D game programming and you don't need top pixel pushing performance, go with Managed DirectX.

Tom Miller had an interesting article on some of the changes they've made to the MDX APIs in order to ensure that they're being used in a performance-friendly way: http://msdn.microsoft.com/msdnmag/issues/05/08/EndBracket/default.aspx