   [MDX] Context Switches?
  Hi,I'm not that familiar with .NET or MDX (happy in my C++ world), but I'm interested.One thing that has me a bit worried is something I heard in reference to developing games with MDX/.NET : context switches.Can anyone clue me into just how this would negatively impact an MDX application, where they would occur and how best to prevent/minimize them?I've done a few searches on google but info was limited and not helpful.  Perhaps there's another term for what I'm describing?Cheers,Brian   
  A context switch occurs when the OS switches from the execution of a thread to another. Basically, the "context" of a thread is the state of the processor registers. This obviously needs to be saved when a thread is stopped, and the state of the new thread is loaded into the registers.This is not MDX specific.If you use threads at all, in managed or unmanaged code, you'll pay for some context-switching overhead. It's hard to detail the pros and cons of multi-threading here, so suffice it to say that if your calculations are parrallelizable, and you didn't go nuts with threads (as in, created a reasonable number of them) the benefit you gain from multi-threading will be greater than the context-switching overhead.Now, what you're probably looking for is garbage collection maybe? In managed code, there's a garbage collector running parallel to your code, and it handles the deallocation of objects when they're no longer used. Depending on the implementation of the garbage collector, this might cause some performance hiccups. For normal (i.e. indie-level) games, I wouldn't worry about it. For hard-core games (e.g., Doom3), I have no idea. I haven't written any, and I don't know of any studios that utilized MDX for such a heavy production.If you misuse the language (C# or VB.NET), you can write code that performes much worse than the unmanaged equivalent. If you write good managed code, it can be anywhere from close to unmanaged performance to better.   ;Quote:This is not MDX specific.Okay!  I was under the impression it was somehow related to managed code interfacing with the non-managed DirectX runtime.As well, I think I might have also been thinking of "boxing/unboxing"; but I am betting this is a general .NET performance consideration, and not specifically MDX.Thanks,Brian   ;Quote:Original post by spartanxQuote:This is not MDX specific.Okay!  I was under the impression it was somehow related to managed code interfacing with the non-managed DirectX runtime.MDX is written using managed C++, which was specifically created for scenarios were managed and unmanaged code need to work together seamlessly, and without performance degradation. The official number by MS, IIRC, is that there's a 5% overhead coming from the MDX layer. Insignificant [smile]   