Jump to content

  • Log In with Google      Sign In   
  • Create Account


C++ or C#?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
51 replies to this topic

#41 razodactyl   Members   -  Reputation: 122

Like
0Likes
Like

Posted 22 October 2006 - 07:41 PM

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

Sponsor:

#42 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 23 October 2006 - 01:11 AM

c# does'nt have this high speed because of itis .NET layer.

this is problem.

#43 C0D1F1ED   Members   -  Reputation: 456

Like
0Likes
Like

Posted 23 October 2006 - 01:42 AM

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.

#44 Promit   Moderators   -  Reputation: 5896

Like
0Likes
Like

Posted 23 October 2006 - 05:21 AM

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

#45 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 23 October 2006 - 10:27 AM

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.

#46 paulecoyote   Members   -  Reputation: 1060

Like
0Likes
Like

Posted 23 October 2006 - 10:58 AM

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.

#47 aero68   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 October 2006 - 07:48 PM

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!




#48 Promit   Moderators   -  Reputation: 5896

Like
0Likes
Like

Posted 26 October 2006 - 08:21 PM

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.

#49 ToohrVyk   Members   -  Reputation: 1587

Like
0Likes
Like

Posted 27 October 2006 - 02:27 AM

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?

#50 Wuntvor   Members   -  Reputation: 170

Like
0Likes
Like

Posted 27 October 2006 - 10:32 AM

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.

#51 Raghar   Members   -  Reputation: 92

Like
0Likes
Like

Posted 27 October 2006 - 04:06 PM

Quote:
Original post by Promit
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.


So you are saying a "new" has nondeterministic duration? That's bad news, for example Java programmers are used to virtually free "new". In fact Java programmers can also use an asynchronous GC. Still probably better than C++, if not for that mutex.

Could C# use multiple stacks, and proper preallocation of memory? What about on stack replacement? Does it have a protection for access into native code? Could programmer choose between fast access into native code, and safe access into native code?

And what about the memory model, did MS properly write the specification?

Of course the major slowdown in GC based languages is when one piece is swapped on the HD, and GC wants to release it at any cost. Considering windoze doesn't have too smart swapping it's bad news.

#52 Promit   Moderators   -  Reputation: 5896

Like
0Likes
Like

Posted 27 October 2006 - 06:32 PM

Quote:
Original post by Raghar
So you are saying a "new" has nondeterministic duration? That's bad news, for example Java programmers are used to virtually free "new".
Yes. I know the architecture of the Java GC (it's very nearly identical to CLR) but haven't actually looked up the trigger conditions. I'll take a look some time in the next couple days.
Quote:
Still probably better than C++, if not for that mutex.
Well the C allocator's also going to execute non deterministically, and it also takes that lock. Except for pathological cases (which seem to be more prevalent in server applications), .NET's memory system performance is fantastic.
Quote:
Could C# use multiple stacks, and proper preallocation of memory? What about on stack replacement?
I don't know what you're referring to with the stacks. Nothing's stopping you from implementing object pools, however. So if you want to use pools to reduce the amount of allocations happening, go ahead. Beware, however, that your perceptions of what constitute bad memory behavior may not be accurate. The CLR Perf guys have indicated that for games, we can allocate about 500K per frame (30 MB/s) of extremely short lived objects without seeing any performance effects at all. I don't know about you, but I was absolutely amazed at how large that figure is. That gives us a lot of memory to play with. 500K/frame. Damn. I can't even figure out what I'd do with that much.
Quote:
Does it have a protection for access into native code? Could programmer choose between fast access into native code, and safe access into native code?
Code executing under the CLR must have the FullTrust permission to call into native code, but if it has been granted FullTrust, it can do whatever it wants. Marshaling costs can be dangerous, as can security checks, so depending on the complexity of the call, you usually want the native code to be a "long" operation.
Quote:
And what about the memory model, did MS properly write the specification?
I didn't read the CLI spec (that's ECMA 335) but seeing as how the compact framework uses a somewhat different GC/allocation subsystem, it stands to reason that the spec only mandates external behavior that would affect applications directly.
Quote:
Of course the major slowdown in GC based languages is when one piece is swapped on the HD, and GC wants to release it at any cost. Considering windoze doesn't have too smart swapping it's bad news.
I don't see how swapping comes into the mix. The runtime is not, to my knowledge, aware of system wide memory pressure concerns, or what's being swapped. A GC is triggered when the current managed heap for the current process is full, and if the heap is still full after the GC, then a new segment is allocated into the heap. (As a sidenote, I've seen your past comments on Windows swap behavior, and I think you're completely and utterly wrong.)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS