4 ms·

As a low-level game dev, I consider C# a nearly perfect, wonderful language, tragically self-defeated by garbage collection.

by psyc 10y ago

noxToken 10y ago
Could you explain why garbage collection in your use case is a bad thing? The GC vs non-GC always fascinates me, and I have no strong opinion either way. Also, doesn't C# have the ability to limit (or pretty much disable) GC?
- InclinedPlane 10y ago
  He's a game dev, says it all. The problem with GC is that often it imposes a performance overhead and, more importantly, it results in non-deterministic performance characteristics. In game dev it's typical to want to be able to complete an entire cycle of computations for calculating game mechanics within a single frame, which could be just 17 or even 7 milliseconds in entirety (60/144 fps). If you get even a fraction of a millisecond delay in computing a chunk of work that can screw up your frame rate, produce noticeable visual effects, etc.
- deleted 10y ago
  [deleted]
- platz 10y ago
  OP probably wants a Concurrent/MarkAndSweep GC rather than a Generational GC. because 16 ms is too much for game dev
- buzzybee 10y ago
  Garbage collection is troublesome for real-time processing(including game engines) because it doesn't allow you to plan around hitting a latency deadline. When the collector triggers, it consumes a lot of time, which can add up to missing a deadline even in very relaxed situations. Historically, many game engines have a "never allocate" policy: Everything is done with static buffers and arenas of temporary data. The broad strokes of this policy are mostly achievable in a GC language that allows value type collections(fewer managed references = less to trace = cheaper garbage). The problem typically comes in little bits of algorithmic code that need their own allocation: Because the language is garbage collected, all your algorithms are using the GC by default. And if you want to reclaim it, you have to fight a very uphill battle. IME, though, most of the problem is resolvable if you have enough introspection into GC configuration. If a game can tell the collector that it needs a cheap scratch buffer to process an update loop and then get thrown out, that covers a lot of the problem. The last bit of it is fine detail over memory size and alignment, which some GC languages do give you introspection into already. Edit: Also, I should note that the relative value of GC changes a lot when your process is long-lived and unbounded in scale(servers) or involves a lot of "compiler-like" behaviors(transformations over a large, complex data graph). The advantage of doing without it in a game engine has a lot to do with the game being able to be tuned around simple processing of previously authored data, with limited bounds in all directions.
- nickbauman 10y ago
  Non-deterministic performance. It can be fast, even faster than managed code in some cases. But it's not predictable.
- catpolice 10y ago
  GC is a no-go for a lot of games in general, just because the periodic stop-the-world cleanup causes unpredictable frame-rate-destroying performance hits. That doesn't matter a lot for some games, but it tends to stutter things like FPSs unacceptably.
- sqeaky 10y ago
  Garbage collection is the bane of smooth framerates. Players notice when the framerate drops. Presuming a pretty typical 60 Frames Per Second you have a tight 16.6ms time budget to do all of the work for the entire frame. All of the physics, all of the sound processing, all of the AI and everything else needs to be sliced up into little bits that can be distributed across the time the game is played. There are many good ways to achieve this, and many ways that just appear good until someone else plays your game. If you allocate dynamically even occasionally you need a strategy to allocated about as much as you deallocate each frame or otherwise mitigate the costs. C++ has this problem completely solved with strong deterministic semantics between destructors, smart pointers and allocators. This can be handled in C# a few ways as well, but sometimes a bunch of unallocated memory builds up and is cleaned between level loads or during downtime. When the Frame rate drops because the garbage collector consumes 1 of the 2 hardware threads in the middle of a firefight players get mad. If you only ever tested on your nice shiny i7 with 8 hardware threads you might never notice until a bug report lands in your inbox. That presumes it wasn't one of the stop the world collections and you couldn't use that last hardware thread better than the GC, both of which negate GC altogether. Done right deterministic resource allocation costs almost nothing. You can get to zero runtime cost and nearly zero extra dev time. In practice a little runtime cost is fine, and a little time spent learning is OK, but a bug report in the final hour before shipping that the frame rate drops on some supported hardware setups but not others is really scary.
  - skybrian 10y ago
    I wonder if the very low-latency GC in Go would be good enough, though? The occasional dropped frame doesn't seem like the end of the world, so long as it remains rare. In practice, most games don't have entirely reliable performance, particularly on low-end hardware.
    - acchow 10y ago
      Gamers hate dropped frames. They can also easily ruin multiplayer games.
    - sqeaky 10y ago
- Jach 10y ago
  Most problems with GC are when most GC implementations introduce non-deterministic latencies, but it can also be because they demand a large heap size to work well. Even if you can swap the GC implementation or turn it off, can you guarantee that when you turn it on, it will only run for < X milliseconds and then stop/allow you to control it again? If you can't, turning it off only buys you a little, unless your language also supports direct [de]allocation. Nim's strategy with GC with plain access to alloc() is pretty nice.
Nelkins 10y ago
It's getting easier with every release to not allocate, with things like ref returns and locals[1] and new types like Span<T>[2]. I think there are more things like that coming in the pipeline[3]. [1] https://github.com/dotnet/roslyn/issues/118 https://github.com/dotnet/roslyn/issues/118 [2] https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md https://github.com/dotnet/corefxlab/blob/master/docs/specs/s... [3] https://github.com/dotnet/roslyn/issues/10378 https://github.com/dotnet/roslyn/issues/10378
- Nelkins 10y ago
  Here's a comment that mirrors my own thoughts, from the comments on that third link[1]: "C# heap allocations aren't expensive and are faster than C/C++. They are even faster than stack allocations (if the stack alloc is too large to be a register) as the stack needs to zero out the memory first; whereas the heap has done this ahead of time. However, they do come at a cost, which is deallocation. C/C++ have both an allocation and deallocation cost. The main advantage is you know when you are paying that deallocation cost; the main disadvantage is you often do it at the wrong time or don't do it at all which leads to memory leaks, using unallocated memory or worse trashing something else's memory (as it has been reallocated). The GC isn't the bad guy; its the liver and blaming it is like blaming a hangover on the liver. However; the free drinks the clr allocation bar gives you are very tempting, and does mean there is a tendency to over indulge so the hangovers can be quite bad... (GC pauses)." [1] https://github.com/dotnet/roslyn/issues/10378#issuecomment-242951724 https://github.com/dotnet/roslyn/issues/10378#issuecomment-2...
  - psyc 10y ago
    Yes, someone always brings up the fact that alloc/dealloc isn't free in any language. But that doesn't change the particular animosity between real-time and GC. Manual is like a flexible payment plan. GC is a debt-collector appearing at your bathroom window while you're on the can.
OniBait 10y ago
You can use things like System.GC.TryStartNoGCRegion and GCLatencyMode.SustainedLowLatency to help mitigate the GC pauses though. There is a lot of work that has been going on with the CLR GC code somewhat recently.
- psyc 10y ago
  What I want is no GC. I might settle for a way to tell it "Do not walk this graph over here, ever, ever." But really, I want to be nowhere near a GC at all, unless it gives me control of pretty much everything it does. I do develop in C#, and I have to work around the GC every step of the way. I really want not to have to work around it, not better work-arounds. For the most part, I simply don't allocate, but that is ugly and non-idiomatic.
Coincoin 10y ago
As a game developer having used C# for two large scale projects, I can tell you that the garbage collector was the least of our worries. Just be a good citizen and don't trash like crazy and the GC will never block in the action phase. Also, don't use the default mono GC, that one is terrible.
- psyc 10y ago
  Ah, but everybody's data is different, and that's the problem with a prescribed one-size fits all, too-clever mem manager. If you need a complex graph with a million nodes, then any heap walk during a frame is a catastrophe, and your only out is to write a custom mem manager within the confines of c#, or put your game's core data structure in a C++ lib.

As a low-level game dev, I consider C# a nearly perfect, wonderful language, tragically self-defeated by garbage collection.

by psyc 10y ago

As a low-level game dev, I consider C# a nearly perfect, wonderful language, tragically self-defeated by garbage collection.

noxToken 10y ago

Could you explain why garbage collection in your use case is a bad thing? The GC vs non-GC always fascinates me, and I have no strong opinion either way. Also, doesn't C# have the ability to limit (or pretty much disable) GC?

InclinedPlane 10y ago
He's a game dev, says it all. The problem with GC is that often it imposes a performance overhead and, more importantly, it results in non-deterministic performance characteristics. In game dev it's typical to want to be able to complete an entire cycle of computations for calculating game mechanics within a single frame, which could be just 17 or even 7 milliseconds in entirety (60/144 fps). If you get even a fraction of a millisecond delay in computing a chunk of work that can screw up your frame rate, produce noticeable visual effects, etc.
deleted 10y ago
[deleted]
platz 10y ago
OP probably wants a Concurrent/MarkAndSweep GC rather than a Generational GC. because 16 ms is too much for game dev
buzzybee 10y ago
Garbage collection is troublesome for real-time processing(including game engines) because it doesn't allow you to plan around hitting a latency deadline. When the collector triggers, it consumes a lot of time, which can add up to missing a deadline even in very relaxed situations. Historically, many game engines have a "never allocate" policy: Everything is done with static buffers and arenas of temporary data. The broad strokes of this policy are mostly achievable in a GC language that allows value type collections(fewer managed references = less to trace = cheaper garbage). The problem typically comes in little bits of algorithmic code that need their own allocation: Because the language is garbage collected, all your algorithms are using the GC by default. And if you want to reclaim it, you have to fight a very uphill battle. IME, though, most of the problem is resolvable if you have enough introspection into GC configuration. If a game can tell the collector that it needs a cheap scratch buffer to process an update loop and then get thrown out, that covers a lot of the problem. The last bit of it is fine detail over memory size and alignment, which some GC languages do give you introspection into already. Edit: Also, I should note that the relative value of GC changes a lot when your process is long-lived and unbounded in scale(servers) or involves a lot of "compiler-like" behaviors(transformations over a large, complex data graph). The advantage of doing without it in a game engine has a lot to do with the game being able to be tuned around simple processing of previously authored data, with limited bounds in all directions.
nickbauman 10y ago
Non-deterministic performance. It can be fast, even faster than managed code in some cases. But it's not predictable.
catpolice 10y ago
GC is a no-go for a lot of games in general, just because the periodic stop-the-world cleanup causes unpredictable frame-rate-destroying performance hits. That doesn't matter a lot for some games, but it tends to stutter things like FPSs unacceptably.
sqeaky 10y ago
Garbage collection is the bane of smooth framerates. Players notice when the framerate drops. Presuming a pretty typical 60 Frames Per Second you have a tight 16.6ms time budget to do all of the work for the entire frame. All of the physics, all of the sound processing, all of the AI and everything else needs to be sliced up into little bits that can be distributed across the time the game is played. There are many good ways to achieve this, and many ways that just appear good until someone else plays your game. If you allocate dynamically even occasionally you need a strategy to allocated about as much as you deallocate each frame or otherwise mitigate the costs. C++ has this problem completely solved with strong deterministic semantics between destructors, smart pointers and allocators. This can be handled in C# a few ways as well, but sometimes a bunch of unallocated memory builds up and is cleaned between level loads or during downtime. When the Frame rate drops because the garbage collector consumes 1 of the 2 hardware threads in the middle of a firefight players get mad. If you only ever tested on your nice shiny i7 with 8 hardware threads you might never notice until a bug report lands in your inbox. That presumes it wasn't one of the stop the world collections and you couldn't use that last hardware thread better than the GC, both of which negate GC altogether. Done right deterministic resource allocation costs almost nothing. You can get to zero runtime cost and nearly zero extra dev time. In practice a little runtime cost is fine, and a little time spent learning is OK, but a bug report in the final hour before shipping that the frame rate drops on some supported hardware setups but not others is really scary.
- skybrian 10y ago
  I wonder if the very low-latency GC in Go would be good enough, though? The occasional dropped frame doesn't seem like the end of the world, so long as it remains rare. In practice, most games don't have entirely reliable performance, particularly on low-end hardware.
  - acchow 10y ago
    Gamers hate dropped frames. They can also easily ruin multiplayer games.
  - sqeaky 10y ago
Jach 10y ago
Most problems with GC are when most GC implementations introduce non-deterministic latencies, but it can also be because they demand a large heap size to work well. Even if you can swap the GC implementation or turn it off, can you guarantee that when you turn it on, it will only run for < X milliseconds and then stop/allow you to control it again? If you can't, turning it off only buys you a little, unless your language also supports direct [de]allocation. Nim's strategy with GC with plain access to alloc() is pretty nice.

Nelkins 10y ago

It's getting easier with every release to not allocate, with things like ref returns and locals[1] and new types like Span<T>[2]. I think there are more things like that coming in the pipeline[3]. [1] https://github.com/dotnet/roslyn/issues/118 https://github.com/dotnet/roslyn/issues/118 [2] https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md https://github.com/dotnet/corefxlab/blob/master/docs/specs/s... [3] https://github.com/dotnet/roslyn/issues/10378 https://github.com/dotnet/roslyn/issues/10378

Nelkins 10y ago
Here's a comment that mirrors my own thoughts, from the comments on that third link[1]: "C# heap allocations aren't expensive and are faster than C/C++. They are even faster than stack allocations (if the stack alloc is too large to be a register) as the stack needs to zero out the memory first; whereas the heap has done this ahead of time. However, they do come at a cost, which is deallocation. C/C++ have both an allocation and deallocation cost. The main advantage is you know when you are paying that deallocation cost; the main disadvantage is you often do it at the wrong time or don't do it at all which leads to memory leaks, using unallocated memory or worse trashing something else's memory (as it has been reallocated). The GC isn't the bad guy; its the liver and blaming it is like blaming a hangover on the liver. However; the free drinks the clr allocation bar gives you are very tempting, and does mean there is a tendency to over indulge so the hangovers can be quite bad... (GC pauses)." [1] https://github.com/dotnet/roslyn/issues/10378#issuecomment-242951724 https://github.com/dotnet/roslyn/issues/10378#issuecomment-2...
- psyc 10y ago
  Yes, someone always brings up the fact that alloc/dealloc isn't free in any language. But that doesn't change the particular animosity between real-time and GC. Manual is like a flexible payment plan. GC is a debt-collector appearing at your bathroom window while you're on the can.

OniBait 10y ago

You can use things like System.GC.TryStartNoGCRegion and GCLatencyMode.SustainedLowLatency to help mitigate the GC pauses though. There is a lot of work that has been going on with the CLR GC code somewhat recently.

psyc 10y ago
What I want is no GC. I might settle for a way to tell it "Do not walk this graph over here, ever, ever." But really, I want to be nowhere near a GC at all, unless it gives me control of pretty much everything it does. I do develop in C#, and I have to work around the GC every step of the way. I really want not to have to work around it, not better work-arounds. For the most part, I simply don't allocate, but that is ugly and non-idiomatic.

Coincoin 10y ago

As a game developer having used C# for two large scale projects, I can tell you that the garbage collector was the least of our worries. Just be a good citizen and don't trash like crazy and the GC will never block in the action phase. Also, don't use the default mono GC, that one is terrible.

psyc 10y ago
Ah, but everybody's data is different, and that's the problem with a prescribed one-size fits all, too-clever mem manager. If you need a complex graph with a million nodes, then any heap walk during a frame is a catastrophe, and your only out is to write a custom mem manager within the confines of c#, or put your game's core data structure in a C++ lib.