Sign in to follow this  
Nefaric

General Questions about C#..

Recommended Posts

I've been reading quite a bit about game programming with C++ and C#. I wouldn't call myself a programmer, but I would really like to learn more. I know some basic C++, VB, and Java. I have read several discussions about C# and heard several different things. I was hoping the people here could clear some of it up for me. I guess C# is a sort of combination between C++ and Java. Having studied Java and independently learned some C++ a while back I was thinking that C# may be the way to go. However, is there any great difference in performance between these languages? Some have said that C++ is faster, and others say it doesn't make much of a difference. I have heard that C# is just plain easier to use overall. I guess I am asking this. Should I refresh myself with C++ and continue to educate myself in C++ with greater depth? Or should I begin learning and making the transition to C#? I want to stay ahead of the times so to speak, and wanted to know if C# is the future or if it is just something that will come and go. Any direction as to which path I should take in my programming education would be greatly appreciated. I'm trying to broaden my horizons while staying up to date with the programmig world! Thank you in advance.

Share this post


Link to post
Share on other sites
I wrote some benchmarks a month ago for work to evaluate the differences in performance between C++, managed C++, and C#.

My tests involved loading around 400MB of data out of a text file into a collection of classes (about a million of them), and then sorting those classes based on their various members (an int, a string, and a double). It also performed a number of mathematical calculations on integers and doubles to evaluate math performance.
Sorting was done with a custom quicksort function, so I could port it between the three language implementations and be sure the algorithm was the same for all tests. I figured the quicksort algorithm was also good for testing recursive performance, as it is massively recursive when dealing with large datasets.
The test also involved a fair ammount of copying large arrays of data.

For most things, C# and managed C++ required twice the processing time of C++. Especially when sorting by strings. The math benchmark was closer, but C++ still edged out the other two.
C++ also used 5-10% less memory.

If you look at all the major game development companies, you'll probably find that they all work with C/C++ exclusively, and there's a good reason for it. Games often need to squeeze as much performance out of the computer as they can. C# (IMHO) is bloated.

I will say this though, C# does make a LOT of things very nice.. as a language it's easy to work with, and the .NET libraries provide a lot of functionality. Just don't expect to write Half Life 2 in it.

Share this post


Link to post
Share on other sites
Performance quotes are always biased based on the authors knowledge. This is true of all benchmarks.

Most games today are written in C++, then again, C# has been on the market for only a short amount of time. Saying that games are still mainly in C/C++ is no surprise, mostly due to the fact that this industry is slow to adopt new languages. The transition from C to C++ was just as slow or slower.

C# does offer significant advantages when developing tools, and that is where you see a lot of game companies changing things. As far as benchmarks go, it runs as machine code, jitted on the machine. As the jit compiler improves, so will performance. The version 1.0/1.1 of the JIT did not include floating point optimizations, so obviously C++ could outperform it there. However, benchmarks of the mathematical functionality by Jesse Towner showed that the .Net math routines were faster than the C++ ones, sometimes by a significant margin. Take that however you will.

Is C# 2x slower than C++? Doubtful, sounds like pragma Fury's benchmarking code might need to be looked at. Of course, it could also be the machine it was run on. It's generally about 80-90% of the speed of C++ though, mostly due to a bit of added overhead due to certain features of the CLR.

So, my recommendation is this: Pick up C++, learn it. Pick up C#, learn it as well. They two aren't so far disimilair as to make learning both too bad. Not to mention, it will make you a more valuable employee [grin].

Share this post


Link to post
Share on other sites
I agree that you wont write HL2 or Doom3 with C#, but heck thoose arent what you could call great or even enjoying game. They are just big demos of a graphics engine but thats all and i wouldnt take them as a benchmark for other games. Some commercial games have been written with C#, Arena Wars and Tin Soldiers : Alexander The Great, so its possible.

As for everything, there are pros and cons. But most dont even know what they are talking about. The only way to make your opinion is to give it a try.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Performance quotes are always biased based on the authors knowledge. This is true of all benchmarks.

Most games today are written in C++, then again, C# has been on the market for only a short amount of time. Saying that games are still mainly in C/C++ is no surprise, mostly due to the fact that this industry is slow to adopt new languages. The transition from C to C++ was just as slow or slower.

C# does offer significant advantages when developing tools, and that is where you see a lot of game companies changing things. As far as benchmarks go, it runs as machine code, jitted on the machine. As the jit compiler improves, so will performance. The version 1.0/1.1 of the JIT did not include floating point optimizations, so obviously C++ could outperform it there. However, benchmarks of the mathematical functionality by Jesse Towner showed that the .Net math routines were faster than the C++ ones, sometimes by a significant margin. Take that however you will.

Is C# 2x slower than C++? Doubtful, sounds like pragma Fury's benchmarking code might need to be looked at. Of course, it could also be the machine it was run on. It's generally about 80-90% of the speed of C++ though, mostly due to a bit of added overhead due to certain features of the CLR.

So, my recommendation is this: Pick up C++, learn it. Pick up C#, learn it as well. They two aren't so far disimilair as to make learning both too bad. Not to mention, it will make you a more valuable employee [grin].


*nods* Thing is a C++ programmer can very easily pick up and program something in C# - but there are slightly different rules and heuristics you apply to your style from C++ that give you performance boosts in C#. So what appears to be a good C# program to a C++ programmer someone with C# experience might be able to pick performance holes in it.

Of course the same goes in the other direction... a C# programmer going over to a C++ enviornment with relatively little experience could write code that looks pretty good in C# land but C++ heads would shake their heads at.

Having now personally had years programming both C++ and C# projects side by side I know this to be true... I knew C++ first and some things that make sense in C++ really are performance dogs in C#.

There are many other metrics to comparing the suitabilty of language then just raw performance anyway. They are stalewarts on the boards... "l33t" coders whom diss everything else that isn't c++. The same thing used to be true of C against C++. Best thing is to make your own judgement. As far as your own projects go there is no reason not to use C#. In fact I would encourage using C# first, just because it allows a developer to concentrate to a greater extent on the design and architecture of a solution rather then the micromanagement C++ demands on memory and resources. It's also far more rapid to actually get stuff to screen (less lines to do stuff, complexity often hidden). The micromanagement of everything though is where C++ draws its strength, but it can easily give people enough rope to hang themselves with.

As far as the development industry as a whole goes, these days most software developers in the real world seem to prefer you to have C++ and either Java or C#. But you'll find knooks where C, ADA, COBOL, Pascal are still heavily used - in non-games development places anyway. Why are they used? Because they are old projects that require maintenance, or the simple fact that the language simply has features that suit the problem domain better. ADA for instance established itself long ago as a military language to guide missles etc, but I'm sure there are other languages used for that same purpose too (likely C and perhaps C++... I doubt C# and Java would be used for missles... or that there is a Windows (tm) for Missles either for that matter).

I mean, personally, I think the Pascal parameter marshalling is still the best out there - but that doesn't mean I choose Pascal for everything just on that strength. Infact it has probably been about 8 years since I touched Pascal! Haha!

When it comes to games use whatever you feel comfortable with and best suites your needs... I mean I bet some of the most fun games you have played recently have been flash based ones on the web. What may have taken a flash developer a couple of days in scripting to do may take a week or more to sort out in another language - plus then you've got to figure out installers and the like where as flash you can just embed on a webpage. But you know that Half-Life 2 is a bit beyond Flash's abilities... then again if you're starting off you aren't going to be making Half-Life 2 are you?

[Edited by - paulecoyote on June 3, 2005 3:57:30 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Performance quotes are always biased based on the authors knowledge. This is true of all benchmarks.

Is C# 2x slower than C++? Doubtful, sounds like pragma Fury's benchmarking code might need to be looked at. Of course, it could also be the machine it was run on. It's generally about 80-90% of the speed of C++ though, mostly due to a bit of added overhead due to certain features of the CLR.


For every comparison that shows C++ is faster, you'll find one that shows C# is faster.
I just told what my benchmarks revealed to me. I ran the tests that I did because the behavior of those tests was similar to what the project I was evaluating the languages for would be doing. I would encourage you to write your own benchmarks, which would simulate the type of behavior your progam will be producing and draw your own conclusions.

Washu, if you wanna look at my benchmark code, you're more than welcome to. The tests were run on our benchmark machine at work, a dual 2.0GHz Xeon box with SCSI drives and 4GB of RAM. Though honestly, I think I've been coding long enough to be able to write a fair test suite.

And FYI: Even with the performance differences we saw, we decided to go with C# anyway, because of the benefits of .NET and the C# language. Also because it's a bit of a marketing bonus.. "ProductX was written in C#!" "OOoooo!" say the marketing people. "That's a NEW thing! And MS made it.. so it must be good"

Share this post


Link to post
Share on other sites
I want to thank everyone for their input. I think I am going to attempt to learn C#. I see that improvements are certainly being made, and I feel that I have enough C++ experience that it may not be that difficult. I am not looking to program the next Half-Life 2, so if there are any differences in performance I don't think it will become much of a factor.

If anyone else wishes to share their input they may certainly do such a thing. I just wanted to share my appreciation.

Nefaric

Share this post


Link to post
Share on other sites
Quote:
Original post by pragma Fury
If you look at all the major game development companies, you'll probably find that they all work with C/C++ exclusively, and there's a good reason for it.

Dead wrong sir. I can name off a ton of major game development studios that use C# internally in tools, tests, applications, etc. I even know of many small to mid-size companies writing complete games in C# or going the C# (game) / native C++ (engine) route.

No offence, but if your C++ code is running twice as fast as the C# version than you have some pretty bad C# code. I have personally developed actual applications and games in C# and have been able to get near 85-90% every time hands down and most of the time > 90% .. so your benchmarks are obviously skewed somewhere.

Language benchmarks are pretty stupid anyways.. it's about the algorithms and how you tackle the problem at hand. I mean bad C# code will run badly, bad C++ code will run badly.. good VB code will outperform bad C++ code.

I noticed you mentioned strings, you used builder at least right?

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
Dead wrong sir. I can name off a ton of major game development studios that use C# internally in tools, tests, applications, etc. I even know of many small to mid-size companies writing complete games in C# or going the C# (game) / native C++ (engine) route.

No offence, but if your C++ code is running twice as fast as the C# version than you have some pretty bad C# code. I have personally developed actual applications and games in C# and have been able to get near 85-90% every time hands down and most of the time > 90% .. so your benchmarks are obviously skewed somewhere.

Language benchmarks are pretty stupid anyways.. it's about the algorithms and how you tackle the problem at hand. I mean bad C# code will run badly, bad C++ code will run badly.. good VB code will outperform bad C++ code.

I noticed you mentioned strings, you used builder at least right?



I was refering to games. Obviously other languages are used internally on tool development. I myself use Python or C# for tools whenever I can get the chance, there's no need to sound offended. I also mentioned that even with our test results, we decided to use C# in our project.. and it's no small project. Our software routinely sells for a minimum of $100K, and often upwards of $1M. Language selection is not decision we take lightly. Use the right technology for the job.

In a graphics engine, even a 10% hit is huge. People spend thousands of dollars on their computers, overclocking their liquid-cooled dual-CPU/cored SLI-capable monsters to get less of a performance increase than that.

Can you name any games that use C#? I'd be interested to look at them.

I'd be more than happy to share my benchmark code with you. If you can point out areas in it that are biased towards C++ over C#/.NET, I'd be happy to accept any constructive comments/suggestions on it.

Yes, it used some strings, but it did not involve string manipulation. As I mentioned in my first post, I specified that the strings were only used for sorting. My benchmarks where meant to give a feel for how the language would perform under similar circumstances to what the project I was evaluating the languages for would be encountering. Using the .NET String builder may be faster for building a string, but my tests conclusively showed that string comparison was definitely faster in C++.

Also recall that the string comparison was being used in a quicksort algorithm. Tests written by other people and published on the internet have shown that C# is significantly slower than C++ when doing recursion. The difference in speed could very well have been because of thoat.

I was asked for my opinion, and I am merely stating what I have seen.

The test also involved taking the quicksort and multithreading it. Running the multithreaded quicksort really narrowed the gap between C++ and C# (down to maybe 10%) but C++ still had the edge.

Share this post


Link to post
Share on other sites
I dug up my test results. C#/C++.NET actually performed better than I remembered in the data loading and math tests. My main concern was the sorting/comparison tests however.



I still would encourage anyone to do their own performance tests, which would be relevant to the solution they are trying to develop.

Share this post


Link to post
Share on other sites
With your sorts and compares were you using generics? I mean I really find it hard to believe. And if you weren't using generics than duh.. of course C++ is going to be faster in sorting due to boxing/unboxing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
With your sorts and compares were you using generics? I mean I really find it hard to believe. And if you weren't using generics than duh.. of course C++ is going to be faster in sorting due to boxing/unboxing.


Yes, I'm pretty sure I was using int/double/string. But I don't feel like going to work to check.

Share this post


Link to post
Share on other sites
Cite of Jeff ... There are lies, there are greater lies, and there are benchmarks.
From that image I could see there are 2 data/math benchmarks, and THREE sorting benchmars. Alas that tells nothing, aside sorting method might be improved in standard library. If you wrote your implementation of sorting and didn't used standard containers, it migh mean that C++ compiler botched it somewhere. (At best it would be in method inlining, at worst by additing an unnecessary code.)
I highly recomend posting numbers, not just graphs. Graphs are main weapon of statisitic, these would support any view. (And more importantly that above image dwarfed result of math benchmark.)

Of course if these would be a test runs of AI, or some expensive calculations, it might be much better. I remmember that Celerons D beat up Athlon 64 fair and square in some of my benchmarks, but Athlon 64 beat up P4 in memory access. (Of course I used Java so this shouldn't be used more than a hint about expected results.)

Share this post


Link to post
Share on other sites
Quote:
Original post by pragma Fury
In a graphics engine, even a 10% hit is huge. People spend thousands of dollars on their computers, overclocking their liquid-cooled dual-CPU/cored SLI-capable monsters to get less of a performance increase than that.


Actually I underclocked my computer, and I consider graphic engine that don't cause a standard P4 cooler to produce sounds of a helicopter a reasonable graphic engine.

Dual core CPUs are just starting. They are nastily expensive, and only multithreaded programs, like multithreaded games, would benefit from them. (Actually majority of programs that I wrote are multithreaded without blocking. I hope you already learned the art of error cancelation, and lazy synchronization. Or better said late synchronization.)

14809,00 / 23 $ (~600$) athlon X2 manchester
27629,00 / 23 $ (~1300$) athlon X2 toledo

When they'd get closer to 150$, you might see them in typical gaming computer.

It's strange, this idea about "1/10 performance gain is critical" is fairly widespread, if we would consider gamedev threads as a statisticaly significant source, but I didn't experienced such demand in last 5 years of work. I however experienced demand "it must scale well on future computers", and "it must be reliable".
And also the demand "it might be very nice even after few years" (by ideas playability and complexity) is very nice to fullify.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this