Is C# part of the problem?

[mazex]

Originally Posted by Thee_oddball

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!

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

[Thee_oddball]

Maze i found a nice read you might enjoy

With Microsoft's introduction of the .NET platform and languages, including its bias towards distributed application components, performance analysis and performance tuning have become substantially more important for today's development efforts. Individual assemblies and Web services that seem to offer adequate performance when unit tested perform unacceptably when integrated as a single application.

One of the biggest, yet largely unexplored, areas of .NET performance concerns the so-called "interop" – the interoperation of managed and unmanaged code in the same application. In most cases, this involves new .NET code calling native code components. However, it's also possible for native applications to call .NET components, although by its nature this is likely to be much less popular.

At this point, many developers don't understand the performance implications of interop. Moreover, they aren't necessarily even cognisant of when their application is performing interop, and what they can do to resolve such problems. In some cases, interop is performed by the .NET Framework, and most developers think it can't be helped. For example, Figure 1 shows the negative performance implications of a line of code that calls into native code indirectly through its children.

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

[MadBlaster]

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?

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.

[Codex]

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.

[Thee_oddball]

Originally Posted by Codex

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.

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

[Thee_oddball]

Originally Posted by MadBlaster

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?

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.

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

[MadBlaster]

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

[Codex]

Originally Posted by Thee_oddball

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

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 Awesome stuff in there.