• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Kixdemp

C++ or C#?

51 posts in this topic

Quote:
Original post by BlueHabu
"C# is faster than C++". That seem pretty bold to me
It's also a claim that doesn't appear anywhere in this thread.
Quote:
However, I have seen no effort to do so.
I can't speak for others, but I feel no obligation to prove myself to others. I've put a lot of time into researching performance. If others aren't willing to spend even a little effort on the matter, that's their problem. I just don't want their ignorance polluting these discussions.

Anyway, the answer had nothing to do with the languages and everything to do with the poster's experience. C++, C#, and most other environments are performance minefields even when you know what you're doing.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Question about Mono from a Mono newbie.

An app compiled with mono can be run as-is on other platforms? As in, I compile a Mono app in windows, I can run that executable in OSX, Linux, other mono supported platforms? I don't have to recompile or anything? The target platform just needs mono installed? Just trying to clarify if thats what you mean. Thanks

J

Another question, from a (lower than) newbie. If I make a project in Mono and I have .NET installed on my computer. Can .NET running my Mono-made program? Does Mono depend on .NET or does it have it's own interpreter/VM?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabuIt would seem with all the "expert engineers/programmers" someone would confirm that C# is faster than C++ by publicly posting their testing environments for scrutiny. When the hypothesis that C# is faster than C++ is proven, it would no longer be considered irresponsible to make such a claim.

well i think 99% of the studies show that c++ or c are faster than c#
whilst that maybe the case, as has been pointed out, for the original poster, since he prefers c# then theyre prolly gonna get more perfoamnce out of it than c++

0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabu
"C# is faster than C++". That seem pretty bold to me

It would seem with all the "expert engineers/programmers" someone would confirm that C# is faster than C++ by publicly posting their testing environments for scrutiny. When the hypothesis that C# is faster than C++ is proven, it would no longer be considered irresponsible to make such a claim.

It seems like there are plenty "C# is God's native tongue" people with an agenda so I don't see any lack of motivation to prove their point. However, I have seen no effort to do so.


If such a survey is done, it should be 'complete', because only then it would carry some meaning. It should include a performance/cost ratio, where cost is the money or hours spend to develop each program. When we say 'faster', do we mean the maximum or the "average"? If I need 3 months to write a C++ program that is 10% faster than the program I would write in C# in one month, and if given one month the C++ program would actually perform worse than the C# one, then which is faster? We're not talking about,say, Python(which I love) or compiled vs interpreted code here, where the answer seems obvious. C# programs are also JIT-compiled into native code.

Note, I don't particularly(or at all) like C#, but this seems a logical question to me.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabu
"C# is faster than C++". That seem pretty bold to me


____ is faster than ____ is basically by definition bold to the point of being wrong. Given one program in one language, I can guarantee I can make you a slower one in any other language. As such, I can "prove" any language is "slower" than any other - and conversly, that any chosen language is "faster" than any other by showing slower examples in any other language.

The current state of compiler technology is that you can eventually produce, if you're an expert, faster programs in C++ than just about any other language, probably.

The fact that in many circumstances you'll have to spend more time optimizing parts of that code than will ever be spent actually executing it on all of the computers it is installed on, for that product's entire shelf life, to achieve this "pinicle of optimization", is a footnote usually skimmed or coughed over in barely audiable tones by those trying to prove some sort of point about C++ being "omg teh superiorz".

And for me? I'm pretty sure I'd produce a more optimized C++ program than a C# one in a given alotment of time for the majority of situations. Not because C++ is somehow superior, but because I've been using it since before it was even standardized - about 10 years - whereas my knowledge of C# is at best fairly laughable.

And this exact same kind of sentiment is what just about everyone who's voiced an opinion here. We're not claiming C# is faster than C++. We're just claiming it's faster for the OP.

Quote:
It would seem with all the "expert engineers/programmers" someone would confirm that C# is faster than C++ by publicly posting their testing environments for scrutiny.


If only it were that simple. Problem is, it's impossible to create the perfect comparison, and even those done by experts are all too often badly flawed - and contradictory even when they arn't. It's the age old question of which is a better tool: the saw or the hammer? The answer depends entirely on wheither you're trying to cut a plank or nail them together. Only in the realm of programming, entire toolsets are heavily intertwined, and even the simple problems tend to be a lot more complex.
0

Share this post


Link to post
Share on other sites
as it is , performance wise C# is at roughly the same level as the java server vm,
which places it slightly behind modern C and C++ compilers,

however this assumes that the C and C++ compilers optimizes for the target platform.

for a dev its easy to make a C++ program run faster on his own computer than an equivalent C# program since the dev can recompile the program and optimize it for his hardware.

This is also true for most opensource applications,

however for closed source projects you might actually get better performance by using JIT compilation since that would allow your end-user to easily optimize the executable for his own hardware. (with java and C# this is done automatically the first time the user runs the software),

the .NET JIT compiler keeps improving, performance gets better and better,
and one important aspect of that is: YOU don't have to do anything when a better runtime gets released. with C++ you would need to buy a new compiler, re-build the project and release a new version.

and finally the most important factor:
managed languages save alot of time, are easier to use, etc,
thus you can spend more time optimizing your algoritms. (the algoritms you use is what makes the real difference between a fast and slow application).

some AAA games today even use interpreted scripting languages quite heavily (python for example) even though they are reasonably slow. WHY ? Simply because its easy and flexible and you don't need every last bit of performance when the game is limited by the GPU anyway.

as for the OP:s question.

if you write everything in C# you might end up using 5-10% more cpu time than you would if you wrote everything in perfectly optimized C++, for a game like liero or soldat that could translate to 4500fps instead of 5000fps :)

for a graphically advanced game you'd probably be GPU bound so it wouldn't matter at all.

for heavy physics etc you could always use a native unmanaged physics engine and thus that wouldn't matter either.

Thus just use C# , C++ is great for writing device drivers, physics engines, a program to find large prime numbers, etc, for actual game logic its mostly an unnecessary hassle.

if you are really worried about performance you can have a look at this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp

it contains some tips and instructions for how to write faster managed code using .NET.

quite many of those hints are valid for unmanaged code aswell though.

the key hints are:
keep memory footprints small to ensure that as much real data as possible fits into the cache. (being forced to wait for a memory load is extremely expensive).
Reflection is slooooooow. (its also very useful though)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by SimonForsman
as it is , performance wise C# is at roughly the same level as the java server vm,
which places it slightly behind modern C and C++ compilers,

however this assumes that the C and C++ compilers optimizes for the target platform.

for a dev its easy to make a C++ program run faster on his own computer than an equivalent C# program since the dev can recompile the program and optimize it for his hardware.

This is also true for most opensource applications,

however for closed source projects you might actually get better performance by using JIT compilation since that would allow your end-user to easily optimize the executable for his own hardware. (with java and C# this is done automatically the first time the user runs the software),

the .NET JIT compiler keeps improving, performance gets better and better,
and one important aspect of that is: YOU don't have to do anything when a better runtime gets released. with C++ you would need to buy a new compiler, re-build the project and release a new version.

and finally the most important factor:
managed languages save alot of time, are easier to use, etc,
thus you can spend more time optimizing your algoritms. (the algoritms you use is what makes the real difference between a fast and slow application).

some AAA games today even use interpreted scripting languages quite heavily (python for example) even though they are reasonably slow. WHY ? Simply because its easy and flexible and you don't need every last bit of performance when the game is limited by the GPU anyway.

as for the OP:s question.

if you write everything in C# you might end up using 5-10% more cpu time than you would if you wrote everything in perfectly optimized C++, for a game like liero or soldat that could translate to 4500fps instead of 5000fps :)

for a graphically advanced game you'd probably be GPU bound so it wouldn't matter at all.

for heavy physics etc you could always use a native unmanaged physics engine and thus that wouldn't matter either.

Thus just use C# , C++ is great for writing device drivers, physics engines, a program to find large prime numbers, etc, for actual game logic its mostly an unnecessary hassle.

if you are really worried about performance you can have a look at this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp

it contains some tips and instructions for how to write faster managed code using .NET.

quite many of those hints are valid for unmanaged code aswell though.

the key hints are:
keep memory footprints small to ensure that as much real data as possible fits into the cache. (being forced to wait for a memory load is extremely expensive).
Reflection is slooooooow. (its also very useful though)


I could offer a counter point for each of your points, and someone could offer one for each of mine, so and so forth.
0

Share this post


Link to post
Share on other sites
For goodness sake, another one of these threads?!?!

Kixdemp - did you even bother looking around for the various threads already around here, and realise what an inonixious question that is? I'll grant you that it is for a specific project... but still.

If you like C# and comfortable in it, do it in C#. A soldat clone is hardly going to be pushing boundaries of either language. You sound like you are more keen to make the game then do it as an academic exercise to learn C++. Think about it this way, you could write poor performing code in both C++ or C# - but in C# you would have the experience and understanding to fix the performance problems.

For you it sounds like the right choice would be C#. For someone with C++ experience (and actually wrote something about liking the language rather then finding it too complex), the right choice would be C++.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by BlueHabu
"C# is faster than C++". That seem pretty bold to me
It's also a claim that doesn't appear anywhere in this thread.

You are right you said
Quote:
Original post by Promit
Performance would probably be (significantly?) better in C#.
Since this is "C++ or C#?" thread what are you comparing if not C++ performance to C#?

Quote:
Original post by PromitI can't speak for others, but I feel no obligation to prove myself to others. I've put a lot of time into researching performance. If others aren't willing to spend even a little effort on the matter, that's their problem. I just don't want their ignorance polluting these discussions.


Well that’s too bad but that’s what computer SCIENTISTS do. We research ideas and topics and post our results. You would think if you had all this research it would be simple for you to post it and if it was proved correct you would receive many accolades for resolving this very volatile and heated issue.

If you are so concerned about the "their ignorance polluting these discussions" then PROVE them wrong. You say you have all this research share it. Let other look at and learn form it. Let others make it better.

On a side note: Does anyone not want to see Promit prove C# is faster than C++?

If you look at the latest issue of Communications of the ACM you will see a nice paper called "What makes a good programmer" The one trait the article said was important yet I thought most programmers lacked was objectiveness. IMO, this lacking trait is polluting these forums more than anything else.

To whoever: Feel free to knock me down some more in ratings. I really dont put much stock in it
0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabu
Since this is "C++ or C#?" thread what are you comparing if not C++ performance to C#?

Actually you have a reading comprehension problem and that is why you are now trying to argue. This is not a "C++ or C#" thread, it is a "C++ or C# for this specific user" thread as stated in the beginning. The user stated he already knows C# and prefers to use it, therefore you just didn't read the full question carefully.

Quote:
Well that’s too bad but that’s what computer SCIENTISTS do. We research ideas and topics and post our results.

Actually that is incorrect. Computer science has absolutely nothing to do with benchmarking compiled source code from various languages. The actual point of computer science (hence the science part) is to build algorithms, factor down algorithms, create larger algorithms based on smaller, and put those together to form a solution for a problem.

Quote:

You would think if you had all this research it would be simple for you to post it and if it was proved correct you would receive many accolades for resolving this very volatile and heated issue.

This is only a volitile or heated issue for someone uneducated or evangelical with a certain technology. Anybody with half a brain would be able to realize that this is a multivariable equation. The first component is the actual running speed of a C++ vs. C# application, and the second component is the user's knowledge and ability to use C++ or C#. If you try to argue using only one of those than you have not solved a damn thing. I can't believe it is so hard for people that are supposed to be studying and building algorithms all day to understand this... although I hope it is now clear after my post.

Quote:

If you are so concerned about the "their ignorance polluting these discussions" then PROVE them wrong. You say you have all this research share it. Let other look at and learn form it. Let others make it better.

Once you realize that this is a multivariable problem, and that if you try and measure an "average developers skill with X language" you will realize it than solves nothing for any problem at hand. There is no blanket answer and is completely based on the developer plus the technology.

That is why Promit's answer is so clearly right in this context, because the user has already said that he prefers and is more comfortable with C# (variable 2), and C# is already proven to be nearly the speed of a C++ application in a vacuum where both are coded in exact efficiency (variable 1). Therefore it is quite easy to see that the OP will have better performance using C#.

Quote:

On a side note: Does anyone not want to see Promit prove C# is faster than C++?

I just proved it. Also if I still had the link (which I once posted here) it showed the Axiom Engine (C# port of Ogre) running faster than Ogre in the majority of cases. Is this because C# is natively faster? Of course not it is because the users knew how to correct some of the mistakes made in Ogre. Also I rewrote a C++ engine in C# at a place I was employed and it turned out to run faster... again due to refactoring and fixing (therefore proving the need for variable 2).

Quote:

If you look at the latest issue of Communications of the ACM you will see a nice paper called "What makes a good programmer" The one trait the article said was important yet I thought most programmers lacked was objectiveness. IMO, this lacking trait is polluting these forums more than anything else.

Actually the most important thing for a developer would be discrete mathematics, algorithms, and logic (as that is the actual computer science.. not the programming part). And it looks like a lot of people don't understand how to break something down, as yourself and others in this thread first did not break the correct question out of the initial post, and furthermore didn't see the equation was multivariable with the second being highly variate to the actual problem (user).

Quote:

To whoever: Feel free to knock me down some more in ratings. I really dont put much stock in it

I wouldn't dare rate you down. Your post was perfect for me to explain the actual concepts and reasoning, I thank you for it actually.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
An app compiled with mono can be run as-is on other platforms? As in, I compile a Mono app in windows, I can run that executable in OSX, Linux, other mono supported platforms? I don't have to recompile or anything? The target platform just needs mono installed? Just trying to clarify if thats what you mean. Thanks
Yup, that's the idea! Mono's JIT compiler is pretty amazing [smile] .

Quote:
Original post by Alpha_ProgDes
Another question, from a (lower than) newbie. If I make a project in Mono and I have .NET installed on my computer. Can .NET running my Mono-made program? Does Mono depend on .NET or does it have it's own interpreter/VM?
Mono and .NET can be installed side-by-side.... Hmmm, I just built all of the Tao examples in Mono, and then uninstalled Mono, and they still ran fine. Maybe Mono mimics .NET byte code..... Mono has its own JIT compiler, which you run by using: "mono MyProgram.exe". The neat thing is that you can run most .NET applications through Mono without any problems without even recompiling for Mono. It's really neat.... Just run "mono MyDotNetProgram.exe" in the Mono console application and you'll see. Works in all Mono platforms too...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabu
You say you have all this research share it. Let other look at and learn form it. Let others make it better.
Partial list. Knock yourself out.

Quote:
Also if I still had the link (which I once posted here) it showed the Axiom Engine (C# port of Ogre) running faster than Ogre in the majority of cases.
Linktronix. It looks like C# falls behind in the cases that are very computationally intense (not a big surprise). There's techniques to relieve that in C, or you can even go ahead and rewrite the relevant bits in C++ (with SSE niceness and such) if so desired.
0

Share this post


Link to post
Share on other sites
Cool thanks for that Ogre/Axiom link Promit, I thought it was gone for good :) Also note that at the time of the benchmarks Axiom was using v1.0 of the .NET framework/C# and so no generics, float performance, etc... which is quite impressive imo.
0

Share this post


Link to post
Share on other sites
why commercial game write by c++?
why graphic softwar write byc++?(3dsmax-photoshap-...)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
why commercial game write by c++?
why graphic softwar write byc++?(3dsmax-photoshap-...)
Well keep in mind that C# is a rather new development, and though Java's been around for longer it's only recently benefited from some of the cutting edge technologies in JIT.

5 years ago, Java performance was questionable at best, and C# was not yet a stable 1.0 release. The big applications now have longer timelines than that. Consider your examples. 3DS Max originally grew as a revision of the original Autodesk product called 3D Studio, a program written for 16 bit DOS in a time when the very concept of consumer 3D hardware was a laughable dream. Photoshop 1.0 was released in 1990 for the Mac OS -- that'd be System 6 at the time. No hardware accelerated drawing, cooperative multitasking environment, etc. Hell, both of these started out as, and may still be predominantly C codebases, not C++. (In fact, the early versions of both of those may have needed considerable assembly code to do what they did.)

Java, in contrast, was created as Gosling's pet project in 1991, and didn't show up as a product until 1995. The JDK releases started properly in 1997.

The very luxury to be able to choose something other than C/C++ is extremely recent. Major large scale applications haven't really had much time to appear, and the ones that have are enterprise level things that most consumers never see. And nobody is going to go back and rewrite millions of lines of mature code in C# just because. That's a recipe for disaster. It's only new projects that can choose. Not to mention that the stigmas surrounding managed code are plentiful, which hasn't helped.
0

Share this post


Link to post
Share on other sites
well im a natural c++ programmer, but c# would be my choice in your shoes... - if you're already comfortable with it, i'd definately do it
0

Share this post


Link to post
Share on other sites
c# does'nt have this high speed because of itis .NET layer.

this is problem.
0

Share this post


Link to post
Share on other sites
In theory, C# is faster than C++. In practice it's the other way around.

How can C# be faster? Well, it adapts to the specific platform. If you want a C++ program to run on any 32-bit PC, you have to compile for the 386 instruction set. The C# version does not force you to do this. If you run it on a brand new CPU it can make use of the latest instruction set extensions, and run faster than the C++ version. When you recompile that C++ version for the modern CPU it will most likely run faster, but it will not run at all on an older processor. Also remember that when you release some software written in C++ today, it is never going to make use of future CPU enhancements.

This makes C# very interesting in my opinion. And since its compiler(s) are constantly improving, it's technically not impossible to make it generate the same optimized code as the best C++ compiler.

There's one important exception that I really have to mention though. When the C++ version contains some assembly blocks using highly specialized instructions, there is no way C# can match it. For example Doom 3 has some SIMD optimized functions, and they are two to three times faster than optimized C++. Since C# doesn't support assembly in any way (except in external libraries) and automatic vectorization is an utopia, there will always be 'C++' applications that outperform C#. Even when not using assembly explicitely, C++ gives a better control over what code is generated. So it's not like C++ is going to be replaced by C#. But it's definitely loosing terrain...

Anyway, this discusses only the theoretical performance advantages/disadvantages of C#/C++. There are many other reasons why people choose one above the other.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by C0D1F1ED
There's one important exception that I really have to mention though. When the C++ version contains some assembly blocks using highly specialized instructions, there is no way C# can match it. For example Doom 3 has some SIMD optimized functions, and they are two to three times faster than optimized C++. Since C# doesn't support assembly in any way (except in external libraries) and automatic vectorization is an utopia, there will always be 'C++' applications that outperform C#. Even when not using assembly explicitely, C++ gives a better control over what code is generated.
On the bright side, when it comes down to that (which it sometimes does), you can break out the C++/CLI and write that SSE code, but have it directly callable from the C#. (Or for non-WIndows platforms, you can use a C API shared object and PInvoke to it.)
0

Share this post


Link to post
Share on other sites
I would be interested to have _REAL_ experience returns about GC during game loop.

Is it perceptible ? Do you think that for a big game engine, after a long time of playing, it would become noticable and evenmake the game less playable ?
Cause except that, execution speed seems only modified by a constant factor, and we all know that it's not _THAT_ important (to not say meaningless)... The only thing that keep me from switching to C# is the fear to have (let's project in the future) 16 threads on a multicore CPU awaiting constantly on one thread doing the slow GC every x sec.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I would be interested to have _REAL_ experience returns about GC during game loop.

Is it perceptible ? Do you think that for a big game engine, after a long time of playing, it would become noticable and evenmake the game less playable ?
Cause except that, execution speed seems only modified by a constant factor, and we all know that it's not _THAT_ important (to not say meaningless)... The only thing that keep me from switching to C# is the fear to have (let's project in the future) 16 threads on a multicore CPU awaiting constantly on one thread doing the slow GC every x sec.


*sigh* not a versus thread?
Still I'll shed some light on this particular misconception.

It all depends on the quality of code you write and how intune it is with how the GC works. GC can be very quick and painless in well-written code. I think I posted a link earlier to a presentation about it, which explains it better then I could in a few paragraphs here.

Many game developers use custom allocators and deallocators in C++ to help stop memory fragmentation and loss of performance over time, rather then use the standard malloc and new. With the .Net GC you get efficient allocation and deallocation via a GC that not only looks after that, but also attempts compression too, squeezing the spaces between memory when a certain hueristic is fired. In .net the this all happens behind the scenes without interference and is part of the various languages, in unmanaged C++ you need seperate libraries / implementations that are an extension to the standard allocators and deallocators, rather then being the standard allocators and deallocators.

Not bashing C++ here, because it's obvious what that can do and I'm sure the .Net Runtime itself is probably a lot of high quality C++ thats been through many thousands of tests and taken many thousands of man hours to create an elegant platform for garbage collection that can be utilised by the .Net languages.
0

Share this post


Link to post
Share on other sites
If I would start with a new engine today I would develop the
Graphics, Sound and Physics in C++ and the rest in
C# (game logic, ai and tools). Pretty much the way Reality Engine looks like.

But I agree with others here, if C# is your number one language, just use it!
Also, developing everything on your on is a huge task theis days,
I havn't tryed it my self but, maybe you should look on a engine like
GarageGame.com or somthing like that ?

Good luck!


0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous PosterThe only thing that keep me from switching to C# is the fear to have (let's project in the future) 16 threads on a multicore CPU awaiting constantly on one thread doing the slow GC every x sec.
A GC is always triggered by an allocation, and so it happens in the context that attempted the allocation.

There is no garbage collecting thread. None at all.

Now, the danger is that a GC takes out a lock, so if another thread tries to perform an allocation during a GC, it will block until the GC has finished. Then again, Solaris is the only system I know where malloc doesn't take an exclusive lock on the heap. And a gen0 GC (the only kind that should happen regularly) is really fast. So in .NET an allocation risks incurring a slightly long GC that may block other threads; in native code, every allocation is guaranteed to incur a slightly long linked list traversal that may block other threads.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueHabu
You are right you said
Quote:
Original post by Promit
Performance would probably be (significantly?) better in C#.
Since this is "C++ or C#?" thread what are you comparing if not C++ performance to C#?

On a side note: Does anyone not want to see Promit prove C# is faster than C++?


The problem is on your side here. People in this thread have been repeating over and over again that there is no comparison between the inherent performance of C# and C++. You, however, insist on the contrary. Perhaps should you consider that you are misunderstanding Promit's statement?

Promit compares the expected performance of a C++ program written by the OP to the expected performance of a C# program written by the OP. The generalization to the performance of all C++ and all C# is your own creation, against which you may choose to argue on your own. Do not expect Promit, or anyone else, to defend incorrect statements that you invented yourself. They're yours, so deal with them yourself.

As for the veracity of Promit's statement, remember that it takes experience and mental effort to write a correct C++ program, which, as can be judged from the original post, are not available here. It seems more likely to me that a novice C++ programmer could easily write programs that are slower than an equivalent program written by an experienced C# programmer. Actually, the contrary would be quite surprising in my opinion. This is the core of the argument here.

If you somehow feel that the programmer's skill is irrelevant to the choice of a language for performance purposes, please explain why. If you want to have your own imaginary version of Promit's statement be proven false, well, there you go: it's false. Happy?
0

Share this post


Link to post
Share on other sites
The one thing that C++ has going for "amateur" game developers would be the amount of existing libraries, in my opinion. This is actually much more important than speed, because the one thing I am concerned about the most when I'm working alone is to get things done.

Sure, there are some game oriented libraries for C#, but their number isn't really high and a lot of them just aren't mature enough yet. So, basically, I end up implementing a lot of stuff myself in C# that I wouldn't in C++. On the other hand, implementing something really is a lot faster in C#, so it really depends on how you want to work.

Do not give in to the lure of speed and being "closer" to the machine. It is (besides the libraries issue) the one thing that always draws me back to C++, but I've found that I am much more effective with C#, and that is more important than having a 10% more fps.
0

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  
Followers 0