If I am not mistaken, C# requires the .NET framework to be available both for development, and to the end user (The game players), and would require them to have this .NET framework installed.
I think it comes with XP, though not absolutely sure, and is available for install on Windows 2000.
So if C# proves to be faster in most cases over C++ with DirectX, then anyone, everyone wanting that game, or any other application, must upgrade. Ah it all makes sense now
The .NET Framework does not come with XP and is is available for other NT operating systems like 2000.
@.NET v1.1 Redis Page
Supported Operating Systems: Windows 2000, Windows 98, Windows ME, Windows NT, Windows XP
It is supported on even Windows 98. Even if this wasn't the case, the only way that this optimization could happen is for them to cripple the C++ demo.... which will simply turn off developers to the idea of using DirectX over OpenGL (which is quickly gaining in popularity).
I was wondering the difference of speed between C# and C++ for a long time ago.
Now I have THE answer. I made a program in C++ and after in C# and believe me, I take few months to write both. The benchmark is only mathematics calculation (intersection ray/plane, edge /sphere, vertex / sphere) and data structure traversal (edges/vertex/triangles). The result makes me with no voice:
55 seconds for C# against 8 seconds in C++ !!!
(This result exclude the model loading and octree partitioning) I wasn't surprised so much because of the VM behind dotnet.
But really I expected less difference because of the hudge positive comments on "C#" regarding the performances.
Considering that you are running an 8 second test, it makes sense. If you were to start timing as you begin the C++ compilation and then end when the program exits then you would get an idea of how the two times relate. With C# you are factoring in the compilation time (one of the reasons that C# has the fastest compiler that i have ever seen, seconds for compilation that would take days with C++). The .NET Framework uses JIT or Just-in-time compilation. This means that it compiles the "bytecode" or MSIL into binary and optimizes it for the current CPU before executing it. If you want to get a decent comparison, run the app for more time then a couple seconds (for instance a game wouldn't run for just a couple seconds). Also the second time that you run the app is much quicker JIT'ing then the first. .NET languages do not have a "VM" they have the .NET runtime which JIT's the parts of the assembly that are being used. It is also very handy for optimization and the runtime allows many useful features like .NET Security, marshalling, reflection, dynamic source compilation, dynamic serialization using reflection, cross-platform deployment etc. These are things that you cant find in a native language and are well worth a couple seconds overall that you might loose each time you a run an app. The framework is also the most extensive, flexible and well-documented that i have ever seen (which is suppressing since it is written by Microsoft but is nevertheless true). The .NET framework is also entirely open-source unlike Java.
Also consider the fact that you are comparing simple mathematical calculations. You are comparing the #1 most difficult thing to implement as efficiently as it could be found in a native language. Also did you optimize the apps for both languages or not, because that will make a big difference? Now if you want to take everything into consideration instead of using a high-specialized test which caters to C++. Consider an entire application such as Axiom and OGRE. The Axiom C# port of the famous OGRE engine actually outperformed its C++ counterpart. It is also much smaller and more maintainable, written much more quickly, is much easier to read and understand, much more extensible, and the same build can be deployed an nearly any OS without and the code-base requires not IF-DEF's and maintenance of different builds. I would consider the entire package and not just a simple test which as NomadRock had put it is very limited in its scope. If you wait for .NET 2.0, you will see what has been tested to be an outstanding 5x speed boost in this already incredibly fast engine. Java even supports JIT'ing now. I don't see why people blindly consider C# to be too slow a language to accomplish anything. This is the same thing that was C was considered to be in relation to Assembly back in the day. C# and the .NET framework make an excellent choice for game development for the aforementioned strengths especially due to maintainability, cross-platform deployment, and rapid application development even if it was to be much slower. But it may take a while because of the stigma associated with managed languages.