106 replies to this topic

[john]

I was surprised to find out that in DirectX, some tutorials were very much faster in C# than C++. What does this imply? I personally prefer C# because it really cuts down development time, but what's making me think twice is performance. If C# is as fast as C++ then why not move to C# ?

[woz1010]

Interesting.

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 :blink:

But it could also be just the way the examples where written, at different times, by different programmers.
Where these examples in C# the same as in C++, so you could run similar samples from both languages and see the speed differences?

[CyraX]

If I am right,
CLI is the thing that works as a layer between your OS kernel and the exe. Thus it interprets EVERYTHING that is compiled. This means that when you run ANY EXE, it is interpreted, much like JAVA bytecode on JVM. Now if you see, C# was being developed ALONG with the CLI. Obviously they know some tricks in the language that CLI has worked out.
May be they will make C# even faster in the coming days...

[john]

But how come Java is considered very slow for games? Don't the new features of C# make a bottleneck (e.g. Garbage Collection is one big example).

[godEcho]

cyrax- the 'cli' in windows was dos. Thats been completely done away with in the NT kernel. Now when you run cmd or command, it runs directly on the kernel, like any other program. Also, programs no longer run through the cli to the kernel.

about java:
Say what you will about java, but if you need a program to run with any sort of efficiency, java sucks. Java doesn't let you use _any_ direct memory addressing modes. While this prevents things like segmentation faults (heh, sort of anyway), it also puts function calling overhead through the roof. I guess you could just minimize function calls.... oh wait, you can't. Everythings an object, so you have to go through 18 layers of abstraction to print something to the screen. Yeah, thats a shame. At least its completely cross platform right? Well, that'd be true if it didnt take them ~6 months to release mac and *nix versions. A full development cycle later, people have either adopted the new version for Sun's new "features" or rejected it because they can no longer service a good % of their clients.

About c#:
I refuse to believe it'd produce exe's any faster than any other ms compiler. If you know anything about the way a exe is put together by a compiler (lookup tables, resolution tables) you'd know there isn't anything microsoft could do to make c# executables any faster. If anything, they'd be slower. c# allows you to incorporate multiple types of languages. This results in a scoping/referencing nightmare (on the part of the compiler).

Whether or not c# speeds up development has a strong relation to what you're doing. C# isn't going to fix my bugs, and its sure as hell isn't going to magically make my physics engine work. The speed of development has much more to do with the experience of the programmer, knoweldge of the language, and understanding of causal relationship between code, and the errors it can produce.

C, was originally about being able to compile the same code on any platform you wanted without too much effort. C++ was an attempt to bring C up to date, and for all of its inconsistencies, it more or less did that. C# is a ploy to heard developers into a microsoft only "solution" to "fix" the problems people have managing a development team.

*ahem*

would you believe that I didn't mean for that to sound so bitter ?

^_-

[void]

Ok, I have heard of these DirectX demos in C++ and C#, I have also heard that the C# appear to run faster because the C++ ones are written REALLY REALLY REALLY badly. If you want to test the true difference in speed between C++ and C#, write your own NON graphics apps in both languages, try to make them almost the same, and you will see that the C++ ones spank the crap out of C#.

[godEcho]

Word.

[woz1010]

godEcho's description is right on the money.

[Paladin]

If you run the demos, the c# apps have a faster frame rate than the c++ demos.

also posted before was the fact that it uses .net framework... remember, using .net c++ code and c# code gets compiled to the CLR first... so, it isn't a good test to just run the demos on a machine that uses the .net compiler. test the frame rate of c# vs. the frame rate of c++ where the c++ app is compiled using the VS 6 or Borland compiler. You should see a difference.

[baldurk]

just to add to godEcho's <s>rant</s>post, I'd say that java isn't applicable for games, but is quite appropriate in other areas

[Chompchoad]

godEcho said:

cyrax- the 'cli' in windows was dos. Thats been completely done away with in the NT kernel. Now when you run cmd or command, it runs directly on the kernel, like any other program. Also, programs no longer run through the cli to the kernel.

godEcho,

Before you correct someone, you should probably check to be sure you understood their post in it's context. I believe that Cyrax was referring to CLI ( as in common language infrastructure), rather CLI (as in command line interface).

CLI is an enormous part of the portability features enabled in the .NET environment, seen in various press release like this one.

Not a flame, just attempting to clarify an earlier assertion.

[godEcho]

I was in no way putting cyrax down, and didnt mean for my previous post (or future ones) to sound so flame-esque. If i have offended cyrax, or anyone else, I appologize. I misunderstood what he meant by CLI, and he didn't clarify. Regardless, I am still of the opinion that his assertion is wrong.

As for Common Language infrastructure, I am not overly familiar with the topic. As for it being part of any sized feature, I have serious doubts that microsoft is legitimately interested in portability. Although the article even goes as far as to say,

Quote

"The main reason [for the submission] had to do with overcoming the customer perception that Microsoft is somehow entirely built on proprietary standards"

I think this is an attempt to soft-soap people. Microsoft is, in fact, and empire. Whether it is evil or not, is personal opinion. They cornered several markets with their "proprietary standards." So obvious is this fact, that it caught the DoJ's attention, so you'll have to pardon me when I take their claim with a grain of salt.

As far as effeciency goes, I'm not sure how adding another abstraction layer for code would help. Its most likely my mistaken understanding again, but I'm not sure how CLI could be for both low-level effeciency and portability.

Quote

"It isn't [for] commercial products. It isn't something you would normally use to develop applications on. It's more of an educational and research-oriented thing,"

"It" being "Rotor" which is their codename for Shared Source Common Language Infrastructure (CLI) implementation.

Perhaps someone can clue me in?

[dgilla]

Keep in mind that the MSIL (Microsoft intermediate language) is jit'ed when executed. While one has the option of disabling the jit compiler, it is active by default. This results in an MSIL to machine code transformation, speeding up C# code performance to nearly that of compiled C++. For trivial programs the difference in performance is negligible, however, as the program grows and deals with more complex data structures, garbage collection is usually required, the performance hit of this can be considerable.

Though I have not seen these C#/directX demos, the first question that comes to my mind is "dose this demo compare the performance of C# to native C++, or that of manged C++". As pionted out earlier, C++ can be complied into MSIL (this is referd to as "Managed C++", this would certainly affect the performance of the C++ application.

A Note on Java (and why its so slow). Java also uses a jit compiler, and the speed of trivial Java code is also close to that of C++. However, Java also employs garbage collection (which of course slows things down. One of the greatest performance drains in Java is not the virtual machine, however. It is the interface to the operating system, Java's IO/memory addressing is quite slow, as well as its interface with system services from the native OS. This is probably due to the evolving nature of the Java platform. Many of its libraries appear to be added as an afterthought, and are not as efficient as they could have bean. This is evidenced by the shear number of APIs this platform entails, many attempting to correct the flaws of there predecessors. .Net, on the other hand, has had the opportunity of learning from some of Java's mistakes, as there seams to be a bit less overhead in making system calls, and the API's are cleaner.

[epsilon]

Hi guys,

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.

Has anyone made also a test to compare ?

kind regards,
Epsilon

[NomadRock]

That is hardly THE answer, everyone knows that a single benchmark tells you almost nothing, because there are almost no situations where one is slower or faster that the other in *every* way.

[SnprBoB86]

.NET 1.0 and 1.1 have unoptimized floating point support.

Although I have not benchmarked it personally, I am told that the .NET 2.0 beta is highly optimized for floating point and even takes advantage of CPU specific instructions.

This means that calculations should become on-par or even faster than those in a regular machine code compiled language like C++

[xeonx]

woz1010 said:

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 said:

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).

epsilon said:

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.

[SnprBoB86]

.NET 2.0 drops support for 98

[davepermen]

what is win98? sorry, but.. why shouln't they drop support for a 6 year old os based on .. how old is dos? :)

[Codemonger]

Interesting topic ... Think of this for a second:

I've seen test where C# output code is identical to VB.Net ouput code, the input is different but the ouput is the same. So if you think VB.NET is slower than C++, then why should you think C# is somehow faster than C++. I find the whole debate interesting, and kind of funny at the same time. I don't think you will find a lot of support of people arguing the speed of VB.NET vs. C++ :D , even though VB.NET is using the almost identical code and the exact same libraries C# is using :tongue:

The newest DX examples in C# are faster than C++, which is exactly when I ditched my undying support for DX and moved on to OpenGL using C/C++. Seems like DX will primarily focus on C# in the future, until XNA comes out.