Some background.  I am interested in making a game, so I ran across the Ogre graphics engine.  Someone has ported it to C# (Axiom) and it runs faster.  This really made me think, because I thought C# would be too slow for making a game.  

Maybe C# can be fast because than Native code you have to dump code for a generic Intel processor.  From what I gather, C# is compiled to native code right before it is executed.  This code is optimized for the processor you are using and it is cached for later use.  So is could .NET be faster because it can get more bang for the buck out of the CPU by utilizing its special features?

http://axiomengine.sourceforge.net/modules.php?name=Forums&file=viewtopic&t=22

----

Just a guess...

Microsoft may be using the adaptive optimization techniques pioneered by SelfLanguage and now in use with HotSpot.  These profile the code as it runs, gaining more information than a typical static compiler has available for.  The JIT can then make more informed decisions about inlining, type-prediction, and other optimizations.

Graphics code often spends a large amount of time in inner loops, so there's more room for optimizations.  Just being able to inline functions that would be deemed "not worth it" under static could save a lot of cycles.  -- JonathanTang
----

Hmm... You'd have thought people designing a graphics framework would know the odd bit about what to optimize, and ran their code through a profiler for some sufficient permutations of input data to make use of the advantages native code offers. As OGRE is mentioned to be v1.0.0, that just might the case. DotNet code is always completely JIT-compiled to native code -before- execution, so I see no reason why it should be any recognizably slower than native code in general. The thing with graphics is that garbage collection lag might be unpleasant (does DotNet do anything similar to Java stopping all running threads to perform a major GC?), but since you can do explicit memory management from C# too, the Axiom people might have worked around that.

I seriously doubt it's about specific CPU features, ever since the 21st century is up and running, most of the "native" code compilers generate are OS calls / API invocations anyway, which you have little control over. If CPUs permit for special operations for graphics processing, like 3D now, the display device drivers, or DirectX/OpenGL would be where their use is located.

--DavidVallner

----

The jitter is designed to allow for architecture-specific optimizations, but it currently doesn't perform any.  The only optimization that happens in a C# program is dead code elimination and inlining of some very small functions.  An optimizing complier (for native code) can generate much faster code, but for most applications it really isn't a concern.  The program may appear to run faster in the CLR because memory allocation happens in constant time, and the cost of freeing memory isn't felt except at GC time.  The CLR does stop all threads for GC, but it uses a generational GC, so the time for each collection is pretty small. -- MichaelSparks

----
CategoryProgrammingLanguageComparisons