quote: Original post by DevLiquidKnight
They don''t really prove that C# is as fast as people on this fourm are saying it is; but I will let you be the overall judge.

Are you kidding me?? Those links actually prove that C# is FASTER than people have been saying it is on this thread!! Thanks for the links!

Breakdown by link order:

1.) Shows that on an unmanaged system C# is right behind C++ and ahead of C. This is dead on due to the math equations and the way they were done. Generics in C# 2.0 will cut the long/double numbers down sufficiently because there is no need to box.

2.) Shows a horribly coded C# program using almost all of the drawbacks of the language and the incorrect methods used. Although I think this link is VERY relevant.

Considering Longhorn is a managed system.. even if you develop in C++ you are going to have to use managed C++ or your application will run slow, buggy, etc. Think of the DOS applications running on Win95 to be exact.

The biggest thing this link shows is the managed C++ benchmark which is just horrid. Although it does have the same drawbacks of the C# benchmark (the author is pretty incompetant with .NET and managed systems).. it shows C# outperforming it!

3.) Wow that is an amazing benchmark. It shows C# performing at over 98% of unmanaged code which is simply amazing considering it is an on unmanaged OS.. wow if we ran this on a managed OS such as Longhorn we would most likely see C# at 150% performance which is simply awesome!

4.) Couldn''t download.. I will when I get home.

5.) You should know this is pure Java hype trying to make it look better than both C++ and C# right? I think we all know the performance benchmarks on the latest version of Java =]

6.) All I can say is WOW. This is a nice benchmark.

C# average score (27.33)
C++ average score (27.63)

WOW! On an unmanaged system C++ barely pulls ahead of C++ with a pretty good benchmark.. I would love to run this on a managed system and check out the performance of C# then =]


Overall those numbers show that C# can obtain over 98% of the performance of C++.. numbers that I wouldn''t even claim. Thank you for supplying links and actually bringing substance to the table.. I haven''t seen a lot of these benchmarks before and they are great to view!

quote: Original post by wyrd
Imperil:
All be it from me to dispute a fellow C# lover, but you keep running on about all of these benchmarks and/or programs that prove how C# is just as fast if not faster than C++.

That is one of the problems with C++, the constant focus on execution speed by its fanatics.

If I am learning a language, or programming techniques, or making some demo apps just for fun, who cares about 10% more speed ? Especially in games where you are waiting on the card anyway the point is moot.

The real advantage of C# is development time, productivity. It catches that you are accessing past the end of an array, has a readable syntax. It doesn't force things on the programmer like having to know what format a function's parameters are and having to match that. Many hours are wasted in C++ with changing (byte *) &myvar to (byte **) &myvar to see if it will work or read the pointer's 4 bytes instead of the data.

I wrote a simple BSP compiler in Delphi (no CSG), it runs my testlevel in 16ms. So what do I need the 10% faster that all C++ users promise for ? Even with 1000 brushes, if it runs in 5 seconds and a C++ version could run in 4 seconds, I don't care.

Maybe a C++ programmer would implement the things I've done with dynamic arrays and lookup arrays with linked lists instead, calling node->next constantly, then it would be twice as slow.

I see people use the most complicated stuff in functions in C++, bit shifting, reusable macros, nested switches, too much (a?b:c) usage, even for functions that run on initialization and are called only once.
C was written for UNIX and 300 baud terminals, so it is full of abbreviations to keep it compact, at the expense of readability.

Even thinking about speed is a negative factor on what you can achieve. Optimize only the innermost loop in the functions that are called in your game loop, not everything. Beginners ask in the beginner forum about the 10% speed advantage of C++ before they have learned what a while loop is and that is a shame. Someone who wants to learn how to program should just do that, even in a slower language, and not worry about which languages makes the fastest function calls by pushing less on the CPU stack.


[edited by - Fidelio66 on January 15, 2004 9:58:13 AM]

quote: Original post by paulsdsrubbish
You know those safety scissors you give to little kids that are just plastic? That''s C# (and for that matter Java), safety but can still cut it. C++ is a modellers scalpel - lots and lots of control but really easy to screw things up.

That is actually a really good example.

Looking ahead to the future as well.. that is how Longhorn is built, in a managed system that is totally secure, because it has been shown that you can''t give developers memory access, complete control over the OS, etc.. because so many major applications have been left with memory issues, buffer issues, etc.. and this is a problem that really needs to get taken care of.

Now the OS controls security and stability instead of each individual application.. the way it should have always been. It is an "Operating System" after all.

quote: Original post by MichaelT

quote: Original post by normalme
i have a few guesses,

is it the syntax of the future?

is it optimized for preformance?

is it optimized for clarity?

is it the language that you can use java with?

C++ is the defacto standard in gamecompanies for creating games.
Anything else you might have heard is nonsense.

Games are created using all languages available. Every time there is a new language there is always someone who blows the hype whistle declaring that language superior. c# is no different in that respect. You should use whatever you feel comfortable with. Later the company you work for will dictate what language preference they have and you will use that.

Please note that this guy is either young or just hasn't been developing that long.

Why?

C++ has not been the defacto standard in game development for that long at all.. only a couple years.

ASM was originally what people used and did so all the way up until about 1996.. this is where you saw a change.

People started developing games (I am talking about professional games here not Little Jimmy's pong version 2984) in C and did so until about 2000-2001.

C++ has now taken the reigns for the past 3-4 years as the top language to use. It used to be a really buggy and horribly optomized language and just didn't have the tools. As time went on the language started forming more and the STL was born giving C++ it's own library instead of "borrowing" one. A lot of developers were still unsure of switching to C++ from C because there USED to be a performance drop due to compilers, libraries, etc.. but these days C++ wings right past C.

So if you think that the main language for programming, and game programming specifically has not changed and has been C++ solely than you are sadly mistaken.

Also you claim there have been new languages where people claim it to be the next best language to develop games on. Can you please list a few?



[edited by - Imperil on January 15, 2004 9:59:53 AM]

quote: Original post by Fidelio66

quote: Original post by wyrd
Imperil:
All be it from me to dispute a fellow C# lover, but you keep running on about all of these benchmarks and/or programs that prove how C# is just as fast if not faster than C++.

That is one of the problems with C++, the constant focus on execution speed by its fanatics.

If I am learning a language, or programming techniques, or making some demo apps just for fun, who cares about 10% more speed ? Especially in games where you are waiting on the card anyway the point is moot.

The real advantage of C# is development time, productivity. It catches that you are accessing past the end of an array, has a readable syntax. It doesn''t force things on the programmer like having to know what format a function''s parameters are and having to match that. Many hours are wasted in C++ with changing (byte *) &myvar to (byte **) &myvar to see if it will work or read the pointer''s 4 bytes instead of the data.

I wrote a simple BSP compiler in Delphi (no CSG), it runs my testlevel in 16ms. So what do I need the 10% faster that all C++ users promise for ? Even with 1000 brushes, if it runs in 5 seconds and a C++ version could run in 4 seconds, I don''t care.

Maybe a C++ programmer would implement the things I''ve done with dynamic arrays and lookup arrays with linked lists instead, calling node->next constantly, then it would be twice as slow.

I see people use the most complicated stuff in functions in C++, bit shifting, reusable macros, nested switches, too much (a?b:c) usage, even for functions that run on initialization and are called only once.
C was written for UNIX and 300 baud terminals, so it is full of abbreviations to keep it compact, at the expense of readability.

Even thinking about speed is a negative factor on what you can achieve. Optimize only the innermost loop in the functions that are called in your game loop, not everything. Beginners ask in the beginner forum about the 10% speed advantage of C++ before they have learned what a while loop is and that is a shame. Someone who wants to learn how to program should just do that, even in a slower language, and not worry about which languages makes the fastest function calls by pushing less on the CPU stack.


[edited by - Fidelio66 on January 15, 2004 9:58:13 AM]

Amen.

I develop in both C++ and C# and my productivity in C# is through the roof.. and you can''t SEE the performance difference at all, because it is only numbers.

Does managed code really run that much faster on Longhorn or does unmanaged code just run slower?

quote: Original post by jyrix
Does managed code really run that much faster on Longhorn or does unmanaged code just run slower?

Managed code gets a moderate speed boost because now the .NET framework is actually native to the OS. It is no longer a framework sitting on top of an OS.. it IS the OS.

Unmanaged code takes a small speed-hit because it is not native to the OS. There are ways to get past this, but the user has to change security settings and allow the unsafe application to run (which will not happen in the majority of cases).


It isn't like unmanaged code takes a HUGE speed hit, or that managed code gets a HUGE speed boost, it is a combination of the two.

The fact that managed code gets a boost and unmanaged takes a hit spreads out the performance on benchmarks.

[edited by - Imperil on January 15, 2004 11:52:31 AM]

quote: Original post by ivashkin
Yes, but just because at that time there were almost no commercial games at all.

I don't know where you are getting this information, but there were TONS of commercial games. I mean sure there weren't whole stores (such as EB) dedicated to them, and the sheer volume of titles was lower, but there were TONS of commercial games and shareware games.

I mean back many many years ago when I was 8-10 years old I owned at least 50-60 commerical games. They are packed away in a box in my storage room for safe keeping to this day! =]

quote:
By the way, there are a lot of Java-games. For mobile devices mostly. Not for PC, of course...

Very true. This is one reason for Microsoft's quick moves with the .NET compact framework in hopes of breaking into this market.

[edited by - Imperil on January 15, 2004 11:55:38 AM]

Imperil against the world!