First, equating the OS's multitasking with the GC pausing your app is innacurate. The time devoted to the latter can and often will be longer. Furthermore, if a gamer is running any significantly taxing processes other than the game, they are inviting the perf hit and can resolve it by shutting down uneeded apps. I don't know many gamers that play Halflife 2 with active apps in the background.

Secondly, many of you here who in one sentence say "you're over estimating GC perf hit" then go on to say in the next breath "sure I wouldn't use .NET for a Halflife 2 or Doom 3 engine". Well, you've made the original detractor's point exactly. There is a calibur of engine technology that cannot afford the possibility of the GC effecting their runtime framerate.

I know from speaking with one of the leads on the XBox Amped snowboarding title that even with the prescribed suggestions here (hold onto your refs, allocate pre-level, etc.) you are still just asking for trouble. You end up having to go through all your code and make sure you're not missing anything and this costs efficiency of your time.

Another thing to consider here is that the word commercial is subjective. THere are commercially downloadable puzzle games that will not be held to the standards of consoles or other games like Halflife 2. By all means .NET is appropriate. But again, if you're building the foundation of your technology for a high calibur game, I prefer to have as near to 100% control over these types of issues, and this includes allocations. You cannot override the way .NET does allocations, you cannot control your own memory address space, and so on and so forth. Granted these are advanced techniques, but they become relevent when writing technology that has to work on multiple systems (XBox, with unified memory limited to 64MB) and when every ounce of performance and determinism is critical.

I find half life 2 locks up for a second or two quite a bit while it loads resources like sounds, if they haven't fixed it by now, it's usually right after a loading screen or going into a new room.

Saying you shouldn't make a half life 2 in C# is like saying you shouldn't win the olympic gold medal in ski jumping: most people couldn't win the gold medal if they tried. Most people here are not going to be able to make a half-life 2 anyway, maybe use all the CPU and GPU power half-life 2 does, but they would probably be used wastefully and inefficiently.

Only a full collect can stop the app longer than 0.1 s. If your app does full collects it's your fault. In non-gc apps you have to manage freeing memory, in gc-apps you have to manage allocating memory. No full collects will be necessary if you don't allocate memory after loading your data.
The GC is more forgiving though, it only stops you app for some time, a missing free/delete will kill your app over time.

Whats wrong with IDisposable and using?

It's not so much the speed that keeps me from using C# but the following:

1) C# and .NET are still young technologies. The next version of C# is bringing
alot of new changes to the language.

2) It still isn't available on many machines and having to include a .NET installer is something I don't want to deal with.

3) Most of my code is already established in C and C++.

In about 5 more years I will probably completely switch to C# for everything :-)

Quote:Original post by Trap
Only a full collect can stop the app longer than 0.1 s. If your app does full collects it's your fault. In non-gc apps you have to manage freeing memory, in gc-apps you have to manage allocating memory. No full collects will be necessary if you don't allocate memory after loading your data.
The GC is more forgiving though, it only stops you app for some time, a missing free/delete will kill your app over time.

Whats wrong with IDisposable and using?

Like I said, its not just GC, its the ability to control allocation, address space.

.NET would have done well to have included an option for reference counting, unobtrusively, unlike AddRef.. in COM.

Quote:Original post by MikeyO
I find half life 2 locks up for a second or two quite a bit while it loads resources like sounds, if they haven't fixed it by now, it's usually right after a loading screen or going into a new room.

What does loading a resource from the hard drive have to do with automatic garbage collection which happens in RAM?

Quote:Original post by MikeyO
Saying you shouldn't make a half life 2 in C# is like saying you shouldn't win the olympic gold medal in ski jumping: most people couldn't win the gold medal if they tried. Most people here are not going to be able to make a half-life 2 anyway, maybe use all the CPU and GPU power half-life 2 does, but they would probably be used wastefully and inefficiently.

Is it just me or does that not make much sense?

Quote:
Even with that, there were still minor hiccups during LOD transitions, GUI transitions, etc. The biggest pauses were during song transitions, and that's just because you can't work around DVD seek times.

No, not "even with that", the point is it took them a lot of time and sweaty paranoid evenings to make sure that the biggest problems were during song transitions. The dev I spoke to bemoaned the GC in Lua for that reason. So if its a problem in a controlled evironment, then I'm failing to see how it gets easier to deal with on a PC?

But again, you are clinging to the GC issue, and avoiding the points made about address space management and custom allocation. Look, if your app doesn't need it, then that's fine. And moreover, I think the common sense approach here is that if you are not shipping a high calibur title then .NET is fine for now. It will probably get beter.

But its definitely a matter of opinion as to whether its "infinitely better" than tracking down memory leaks. I know that I don't have to work very hard anymore to avoid memory leaks in C++ with all of the tools and techniques. Its easy to start doing things in .NET where allocations are happening behind your back and this rule is harder to enforce.

Judging by the reactions to this thread, there is a mixed opinion on this. So go and use what works for you.