Is C# part of the problem?
 

Hi. I read C# is popular and CLoD apparently uses it. I also read that it uses interpreter/JIT comp and managed heap/garbage collection. I read that the garbage collector kind of has a mind of it's own (non deterministic). Anyway, the garbage collection is suppose to put an end to the memory leaks? But, CLoD has the memory leaks??? So wtf is on that. I think maybe if you have to write the multi thread and the garbage collector is doing wtf, you gonna get some problems! Also, read JIT has some real-time overhead. So I wonder about that. So, did 1c just make a mistake with C# and this game and should have stuck with what they know like C or C++ or some other older imperative fully compiled language they have more experience in? Maybe C# just not a good choice?. Just my speculation as I read my compiler book. But it would be interesting to hear opinions from the progs on this board.:cool:

There is a garbage collector in C# but it is best to dispose of objects with code yourself when they are finished with which is more efficient.

I remember reading this a while back...dont know if it applies though

Attempting to second-guess the garbage collector is generally a very bad idea. On Windows, the garbage collector is a generational one and can be relied upon to be pretty efficient. There are some noted exceptions to this general rule - the most common being the occurrence of a one-time event that you know for a fact will have caused a lot of old objects to die - once objects are promoted to Gen2 (the longest lived) they tend to hang around.

In the case you mention, you sound as though you are generating a number of short-lived objects - these will result in Gen0 collections. These happen relatively often anyway, and are the most efficient. You could avoid them by having a reusable pool of objects, if you prefer, but it is best to ascertain for certain if GC is a performance problem before taking such action - the CLR profiler is the tool for doing this.

It should be noted that the garbage collector is different on different .NET frameworks - on the compact framework (which runs on the Xbox 360 and on mobile platforms) it is a non-generational GC and as such you must be much more careful about what garbage your program generates.

From what I understand they use C# for the GUI and the scripting, just like IL2 used Java for the GUI... Most games use a more user friendly language for the scripting like Python (which is rather confusing in a way though ;)), the thing is that it comes without saying that the scripting part has to be JIT compiled ;)

I'm pretty sure the game itself is coded in C++

Well - my oh my, at this point to not look silly I loaded Reflector to just verify that the core dll:s where C++ dll:s and not .NET and to my amazement the majority are really .NET assemblies, with a small bunch like the SpeedTree dll:s etc written in C++. Hmm, writing the core of a game like this in .NET feels very weird - I actually never thought of it as I was so sure that it was only the GUI and Scripting which felt OK...

A view in reflector of the core.dll that I thought was a C++ dll below... The "WLandscape" class in the image sure is a part of the render code that is in .NET as you can see... Or is it maybe just for the map editor? Nah, no need for "renderSunGlare" there?

Attachment 8913

EDIT: Interesting looking at the methods... Like cHQ_forestHeightHere(float x, float y)... Could be used to see if you should crash into a tree without actually checking the 3D tree object itself? ;) And then there are a bunch of unmanaged types returned so there sure is interop going on (naturally)... Needs some more digging on what is done in C++ and what is done in .NET. I really don't understand why someone would come up with the idea to write a game like this in .NET. For an Indie game with no real preformance bottlenecks like Magica - sure. But this?

Also remember no garbage collector can stop resource leaks if the code is badly structured and leaves things open that are no longer needed. The garbage collector will just assume its left open for a reason and leave well enough alone.

so your saying that over a period of time alot of "stuff" is winding up in gen2?

get it to market faster?, use smaller team? or both. you think this maybe the reason for the micro stutters and leak?

This is my fear. I wish I could offer more insight, but I just started reading about programming since January and I never read a C# book. So very newbie. Interesting responses so far. :cool:

Didn't the original Il2 Series use Java as it's scripting language? (Though not available to mission designers)

I would have thought that C# would have been a bit more efficient. (Could be wrong though!)

Well, I started working as a C++ developer in the mid 90:ies and switched to C# in 2006 for those reasons so I agree, if it would have been a business application... C# is an easier language to work with in general and If you have a team that includes junior developers doing businesses applications there is no debate on what to choose, the benefits of the .NET framework for business apps is a real boost too, as you have base classes for most everyday needs like talking to web services, mail servers, mq servers etc..

For gaming though it's a different story... The benefits of all those base classes in the .NET framework are really minor as most of the code is maths anyway, and one can assume that game developers know how to allocate and deallocate memory as you can't just let the framework do your cleanup if you use millions of objects that is rare in a business app. You just can't have a GC collect when doing 100 fps. And you really need 100% performance and then C# is not the best language... Sure there are many claims lately that a well written C# program is just some percent slower than C++, the problem is that a sloppy C# program is not. You leave too much in the hands of the runtime, and when tuning performance you are not in full control. And then you have the problem that most of the external libraries that you use in a game are written in C++ (like directx and speedtree) so to use them you get what is called Interop, which is when you go from managed code to unmanaged code, where managed code is the C# code where the memory is managed by the. NET runtime as opposed to the unmanaged code written in C++. And interop costs peformance when you context switch between them. It works a lot better today than in the first versions of .NET and I remember a project where we tried to use a mixed C++ / C# in 2005 where we had to ditch it and go back to unmanaged code as the memory demand increased and we lost too much performance... And in the end it was not that much faster to use C# as it was a team of experienced C++ developers.

There are many games popping up these days written in C#, mainly by small indie teams using some generic 3D engine like Unity3D, but all the bleeding edge games are written in C++... And I don't see that changing as you loose control and performance to be able to have an easier programming language...

/mazex

Good read Mazex. Maybe Luthier knows this now.:-P

nice post maz thnx for the info now i know what interop means :) I have a question i think you would know the answer to...if i started writing a game using OPENGL but half way through decided to with just directx how difficult would that switch over be?

Well, I'm not a game developer even though I once tried but got tired when the collision and response made me realize how much work it is. As the actual render code where the objects are actually drawn to the screen is not THAT big part of the code base I guess it would not be that hard if you are not dependent on features that don't overlap. Most of the time OpenGL and DirectX follow each other functionality wise so I guess it would not be that hard - many games ten years ago had it, like IL2 of course ;) But as I've only done DirectX on an amateur level I'm just guessing...

This is my only game attempt from 2005 so I'm really not in a position to criticize CloD ;) It had awesome fps though ;) 500+ if I remember it right... It's a lot easier talking than doing it yourself ;)

Hmmm. Are you speaking in code???:confused:

Sorry, couldn't resist.:grin:

nice pic...thats better than %99 of us will ever do , you might get a kick out of this..it was a flight sim for Linux that was made between 2002 to 2004 called Gl-117 http://www.heptargon.de/gl-117/gl-117.html.

and if you have any desire to do any kind of programming for a flight sim try this one..its open source . http://www.flightgear.org/

S!

from what I have read the game started out using OPENGL but later switched to DirectX :)

Thanks for the links, hadn't heard of GI-117 before but I've had some fun with flightgear!

The hobby project I'm thinking of now is actually doing a small game in Unity3D as I realized that my last project from scratch was way too much work... And with kids and challenging daytime work as a development manager there is little time left. The dilemma is that at work I haven't done any real programming the last five years so I need my fix ;) For a therapeutic project like that C# will be perfect... Just the logic and no plumbing!

/mazex

Maze i found a nice read you might enjoy


heres the whole article http://www.developerfusion.com/artic...t-performance/

These points stand out.

"Now here's the rub. Marshalling is computationally expensive, and the more data you move back and forth, the more expensive it becomes. Marshalling data structures one way can add as much as 3,000 instructions to your processing time for complex data. "


"By investing a little time early in the development phase, you can ensure that you made the right performance choice and not have to go back and make substantial changes after you have a working application. "


Can we call CLoD a case study at this point?:-P

Jmho, the author comes across bias to managed mode programming. It's a good article though. Hopefully CLoD coders have access to the tool(s) the author speaks about to optimize the interop.

Memory leaks can occur in any language, no matter if a garbage collector is present or not. It's comes down to following good coding practices, it's especially important when making interop calls.

For me I have no doubt that CloD is written in C# due to early error messages people were posting after release. Also the only official Microsoft "Direct X" API that operates on .NET is XNA, however this is capped at DX9 so you can safely say that they CloD is making calls to the un-managed version of Direct X which is the current main stream API of choice.

Maz is right, interop calls are taxing and I wouldn't be surprised it that has been the main cause of all the issues because I get the "feeling" that this style of programming for a game is still in it's pioneering days.

Thanks, that's a good article about why we changed back to C++ for our project ;) Unfortunately, in the period around 2005 many deveopers where experimenting with mixing managed and unmanaged code, so I can understand how they thought at that time. I'm pretty sure they would have thought differently today?

/mazex

Found an interesting article with a benchmark of managed vs unmanaged DirectX... As you can see the interop hits the render performance hard...

http://code4k.blogspot.se/2011/03/be...1-apis-vs.html

But SharpDX looks interesting...

From the summary:

"Ok, so if you are a .NET programmer and are not aware about performance penalty using a managed language, you are probably surprised by these results that could be... scary! "

try this article http://www.codeproject.com/Articles/...-Csharp-vs-NET

Another great article. Most of it I have to take in at a high level due my limited knowledge. I would guess the Suduko test involves heavy recursion/backtracing to compare memory allocation/de-allocation times of heap-dynamic arrays (C#) verses stack-dynamic arrays (C++)? Anyway, I'll bookmark this one for re-read in few months. In the meantime, I'll throw his gc quote on the pile as this guy seems an expert to me.

"Memory management concerns (not benchmarked here) are different in C# than C++. In particular, C# memory allocations are extremely fast, but the garbage collector is a wildcard: it may be fast or slow depending on your memory allocation patterns. And Microsoft has not provided any good way to measure GC performance. There are various guidelines to optimize GC: let objects die young where possible, avoid thick pointer trees (e.g. linked lists or SortedDictionary, a red-black tree), and so on; but it's really outside the scope of this article."

did they really start writing this in 2005 in .NET 2.0?

nice read :) SharpDX does look good :) i wonder what CLoD uses?

Thanks for this link! I've been programming professionally for only a couple of years and I was told to subscribe to CodeProject from day one. I've never found that article :P Awesome stuff in there.

Yup, a lot of good stuff there. If you don't hang out at stackoverflow I can really recommend their forums too. Extremely active for all kinds of programming discussions... That's where the really hairy guys spend their nights ;)

/mazex

yep stackoverflow is my homepage when I'm working. :cool:

here is another engine for you Maze it Use's the ogre3d render http://www.neoaxis.com/
http://www.ogre3d.org/


huh? maze did you delete your post?

Moved it to a separate thread as it was off topic ;)

Just found this thread. Actually I'm a little shocked that CloD is coded in C#. :confused:

I wouldn't want to give so much control out of my hands, when I'm aiming for max performance. C++ is a good compromise, if you want execution speed, manageability of code and development progress. Are C++ developers so expensive these days?

Looks like our investment in hardware only buys us cheaper and slower implementations.

Yes, but these implementations are faster to code, debug and maintain. This is supposed to allows us to get way more complex and reliable software in shorter time.

The result doesn't match your equation in regard to CloD. :-P

Great evil lurks behind a word "supposed" :evil:

I don't think C# is the main problem. It all looks like the developer has hard time managing the project. The inability to give us even an estimate of patch release dates and content is showing a serious lack of control over the life cycle of CloD. I assume they are doing their best to deliver what they can. Trouble is they probably don't have a real plan and are learning what project management really is on the fly.

Also remember that too late in a project there is little to be done. After a certain point even adding extra staff does not help as the time cost integrating them and bringing them up to speed out weighs the benefit of the extra manpower.