is possible to make advanced games with C#?

Started by
26 comments, last by markadrake 16 years, 11 months ago
Why am I getting the feeling of Deja vu with this thread? ;)
Advertisement
Another thing you might look into is Visual C++ with Managed Extensions. This will allow you to program in a safer C#/Java like environment with the 'option' to use C++ features. This is much like writing a program in C/C++ and having the 'option' to use assembly.

KW.
Quote:
The current stereotype is C# is slower than c++ maybe some of you c# proponents could run an few tests and prove the stereotype wrong instead of shooting people down. Flaming ejele for not justifying his claims then claiming c++ code is so badly written its slower(markadrake) with no evidence is hypocrisy.

Here's the thing. Benchmarking languages is pretty much meaningless. A language itself is little more than a gloried BNF grammar and some assorted rules as defined by the language's standard. When people discuss the relative "performance" of "language X" versus "language Y," then those people are doing one of two things:

a) demonstrating their relative ignorance of the field of computing and language theory, or
b) eliding (because it is understood, hopefully, by all parties involved) the assertion that the comparison is less to do with X versus Y and more with particular implementations of those languages being applied to particular solutions to particular problems.

ejele's comments about the relative performance of C++ versus C# seem to be grounded firmly in the realm of (a), since he has never bothered to follow up with concrete evidence of anything.

Furthermore, when we consider (b), we note that it deals entirely with specifics. Benchmarking those things is exceedingly difficult, because performance, in general, is a very fickle thing influenced by a number of subtle factors. Many C++/C# benchmarks are exceedingly flawed, written by people without sufficient experience in one or both languages; C++ and C# (and any two languages, in general) are far too different in underlying paradigms and concepts they use to be compared naively by using nearly-identical (as near as is required to compile) source code -- but that's what most "benchmarks" do.

The problem with benchmarks is that they are not conclusive, especially performance benchmarks, since (again), performance is such a subtle thing. You cannot make definitive unilateral claims about performance (especially between something inherently non-performant like a language). But that's what ejele (and others) are doing, and that's why they are more than deserving of the criticism they're getting.

Benchmarks can only provide conclusive results within constraints; that is, based upon the context of the benchmark. It is trivially true to write benchmarks in any two languages that illustrate that either language is "slower" than the other, just by doing stupid things like putting in delays. Those benchmarks are obviously flawed and there results useless. But this is exactly the same problem most C++/C# benchmarks have, although the problems are usually a little harder to detect than simple delay loops.

The reason people challenge claims like ejele's are because the results of a benchmark are useless without the benchmark itself -- the actual code used, the way the code was built, and the conditions under which the code was executing. Until such time as that code is provided, any claim using the results of the benchmark is bogus; and even once you have the code, again, the benchmark does not provide a definitive assertion that is correct in general, just some conclusions that can be extrapolated to a small degree within the context of the benchmark.
Quote:Original post by RobN
The current stereotype is C# is slower than c++ maybe some of you c# proponents could run an few tests and prove the stereotype wrong instead of shooting people down. Flaming ejele for not justifying his claims then claiming c++ code is so badly written its slower(markadrake) with no evidence is hypocrisy.


It is hard to prove it wrong as any benchmark is biased, as soon as you move above assembly language you will rely heavily on the compiler for performance.
there are situations where for example icc can give 15-20% faster code than mvsc(express or standard) using the same source and others where they are close to equal. (pro versions and above of msvc has more advanced optimization methods avaliable though and generally gives performance on the same level as icc on the x86 platform)

as it is today the high end c++ compilers do often produce slightly faster code than .Net on the x86 platform. (However the best C++ compilers are not free)

Oh, here is a little benchmark showing Java (Or more precicely, Suns Java Server VM) kicking G++ (a popoular C++ compiler) in the nuts
http://kano.net/javabench/

Ofcourse the author is a bit of a Java fan so its probably biased (and he only tests with i386 or i686 optimizations) but it still shows that Java is fully capable of beating some C++ compilers in some situations.

Edit: Sourcecode for the tests are avaliable, the author ran the tests on a intel P4 cpu (the C++ programs were only using P2(i686) optimizations), so there are definitly easy methods to further boost performance of the C++ programs there. -march=pentium4 is one way -mfpmath=sse -msse -msse2 is another however by using those compile flags it would only run on P4 or equivalent (or better) hardware, Java and C# optimizes its code when the user runs the programs and thus always optimizes for the current hardware. (You can work around this with C++ by either releasing the sourcecode or by releasing multiple binaries)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Quote:Original post by jpetrie
The reason people challenge claims like ejele's are because the results of a benchmark are useless without the benchmark itself -- the actual code used, the way the code was built, and the conditions under which the code was executing. Until such time as that code is provided, any claim using the results of the benchmark is bogus; and even once you have the code, again, the benchmark does not provide a definitive assertion that is correct in general
Exactly, and you'll note that I specifically refrained from making any claims of my own when I challenged ejele to back up what he was saying. I have no doubt that there are probably situations for which results such as those he speaks of can be produced, but the questions I'm interested in are:
  • Are those situations particularly relevant? Is the test-case he mentions something that's likely to be generally applicable to a significant portion of programs?

  • Was the test-code actually a correct optimised and idiomatic usage of both languages tested, or are the results flawed by one of the languages being used incorrectly/poorly.

  • Has he actually either done or seen the tests, or is he just spouting made-up statistics?

- Jason Astle-Adams

If you know Java I would stick with that for the time being, Java will force you to code using OOP methodologies as it's an OOP based language which will teach you good programming habits, so when you come to learn C++ you will 'think' in OOP rather than procedural as it can be quite difficult to snap out of lol, whatever you learn in Java your be learning 90% C++ anyway, so have nice cup of Java, I'll be joining you for one ;o)

visit the site http://www.runescape.com - this is an browser based RPG
created by Jagex Ltd, and guess what they used? yep, you guessed, JAVA :) so go have a cup :)*hehe*

[Edited by - Virtual X on May 11, 2007 2:17:52 PM]
1)Myst was made using HyperCard. Nough said.
2)By the time you will be able to make an MMO at all, and since you don't have to work with the limitation the pros have, you will also be able to juggle multiple languages using them as merely tools to complete an objective, making your dillema mostly moot.
Quote:Original post by Antheus
The quality of coding is the same, regardless of language.

The different is, poor coding in C# or Java will result in slower execution, and occasional NullPointerException with a stack trace.

Poor coding in C++ will result in 28,000 memory leaks, 4500 synchronization issues, 58,000 portability/incompatibility problems, 340 language/compiler incompatibilities, and random segfaults without a hint of where, why and how.


What I meant is typically the programs written in C++ are more error prone as the C# ones - for the exact reason you mentioned - C# is simpliar.
Mark A. Drake
OnSlaught Games
Mark Drake

This topic is closed to new replies.

Advertisement