5 ms·

That's assuming you can do all your other calculations in 0ms, which is unrealistic.

by mrob 12y ago

stcredzero 12y ago
But it's usable for an upper bound.
- comex 12y ago
  Here's another way of seeing it: if your target tick rate is 60Hz (~16ms), when the GC decides to trigger a collection, you lose most of your time budget. You'd have 6ms left on average, sometimes less, so to avoid dropping any frames you'd probably want your tick routine to complete in 5ms. In other words, when it comes to work that must be done every tick (which is probably most of it), you could only safely use less than a third of available CPU time! I guess dropping a single frame on occasion may not be that bad, and the GC parameters could be retuned (and other GC languages have lower latency), and you could minimize the amount of garbage created, but still, that's not a good situation to be in.
  - tormeh 12y ago
    What I've heard is that games aren't particularly heavy on the GC anyway, because they load in the objects in the level and then they don't create much else in terms of objects. There's just not all that much to be collected. I guess it's a bit more complicated for open-world games that need to load and delete game world objects on-the-fly, though.
    - aethr 12y ago
      It depends. Sure you can preload all your world props and level entities, but what about things like projectiles being fired, travelling, and then being de-allocated? A good strategy for handling this in a GC'd language is using the factory / pool patterns, so during level loading you instantiate 100 "empty" projectile entities that you can re-use. When a projectile is "fired" you request a Projectile from the ProjectilePool, add its initial position/speed/whatever, then add it to the world. It goes through its trajectory, maybe hits a wall, and then you release it back to the ProjectilePool where it is cleared and can be re-used later. But what if you need 101 projectiles...?
      - AYBABTME 12y ago
        How big would a projectile be? I'm not super familiar with how games encode their state, but I doubt things like projectiles would account for much memory. Which makes me think that it wouldn't cause problems with GC. Just guessing =P
        aethr 12y ago
        That's true, but as slimsag pointed out below, long GC pauses (which are what we're trying to avoid) are caused by large numbers of heap-allocated objects, not by the size of the objects.
      - chipsy 12y ago
        The 101 projectiles case is not such a useful what-if in practice. It's a game, so your final tuning comes down to "what will hit my framerate target and memory budget," not what a user requested. If it struggles to keep up with 101 projectiles, you have to either design it down or accept dropped frames in the most demanding situations. So a pool's size limit acts as a guide for the other budgeting considerations anyway - and it plays well with the traditionally constrained memory budgets of console games. Of course, AAA game engines today will employ custom low-level allocation strategies in order to squeeze out the last few percentage points where they deal with dynamic data - but if your aims are more modest, and you harken back to 80's era gaming, most of those games had a nearly or entirely static memory map. Besides being a poor fit for those tiny microprocessors, dynamic allocation enables out-of-memory and fragmentation errors to exist, leading us back to the "hard limits on instancing" strategy again. GC still incurs overhead where it has to trace, even if you've pooled everything. Reference counting pulls ahead of tracing collectors in the situation of heavy object persistence, despite being more expensive as a general allocation method. As well, it has predictable latency, which is more important for meeting real-time requirements. (N.B. as systems parallelize, they become more bound by latency considerations. Seven workers may finish early, but delivery will still get bottlenecked by the eighth slow one.)
mseepgood 12y ago
You both are "calculating" nonsense

That's assuming you can do all your other calculations in 0ms, which is unrealistic.

by mrob 12y ago

That's assuming you can do all your other calculations in 0ms, which is unrealistic.

stcredzero 12y ago

But it's usable for an upper bound.

comex 12y ago
Here's another way of seeing it: if your target tick rate is 60Hz (~16ms), when the GC decides to trigger a collection, you lose most of your time budget. You'd have 6ms left on average, sometimes less, so to avoid dropping any frames you'd probably want your tick routine to complete in 5ms. In other words, when it comes to work that must be done every tick (which is probably most of it), you could only safely use less than a third of available CPU time! I guess dropping a single frame on occasion may not be that bad, and the GC parameters could be retuned (and other GC languages have lower latency), and you could minimize the amount of garbage created, but still, that's not a good situation to be in.
- tormeh 12y ago
  What I've heard is that games aren't particularly heavy on the GC anyway, because they load in the objects in the level and then they don't create much else in terms of objects. There's just not all that much to be collected. I guess it's a bit more complicated for open-world games that need to load and delete game world objects on-the-fly, though.
  - aethr 12y ago
    It depends. Sure you can preload all your world props and level entities, but what about things like projectiles being fired, travelling, and then being de-allocated? A good strategy for handling this in a GC'd language is using the factory / pool patterns, so during level loading you instantiate 100 "empty" projectile entities that you can re-use. When a projectile is "fired" you request a Projectile from the ProjectilePool, add its initial position/speed/whatever, then add it to the world. It goes through its trajectory, maybe hits a wall, and then you release it back to the ProjectilePool where it is cleared and can be re-used later. But what if you need 101 projectiles...?
    - AYBABTME 12y ago
      How big would a projectile be? I'm not super familiar with how games encode their state, but I doubt things like projectiles would account for much memory. Which makes me think that it wouldn't cause problems with GC. Just guessing =P
      - aethr 12y ago
        That's true, but as slimsag pointed out below, long GC pauses (which are what we're trying to avoid) are caused by large numbers of heap-allocated objects, not by the size of the objects.
    - chipsy 12y ago
      The 101 projectiles case is not such a useful what-if in practice. It's a game, so your final tuning comes down to "what will hit my framerate target and memory budget," not what a user requested. If it struggles to keep up with 101 projectiles, you have to either design it down or accept dropped frames in the most demanding situations. So a pool's size limit acts as a guide for the other budgeting considerations anyway - and it plays well with the traditionally constrained memory budgets of console games. Of course, AAA game engines today will employ custom low-level allocation strategies in order to squeeze out the last few percentage points where they deal with dynamic data - but if your aims are more modest, and you harken back to 80's era gaming, most of those games had a nearly or entirely static memory map. Besides being a poor fit for those tiny microprocessors, dynamic allocation enables out-of-memory and fragmentation errors to exist, leading us back to the "hard limits on instancing" strategy again. GC still incurs overhead where it has to trace, even if you've pooled everything. Reference counting pulls ahead of tracing collectors in the situation of heavy object persistence, despite being more expensive as a general allocation method. As well, it has predictable latency, which is more important for meeting real-time requirements. (N.B. as systems parallelize, they become more bound by latency considerations. Seven workers may finish early, but delivery will still get bottlenecked by the eighth slow one.)

mseepgood 12y ago

You both are "calculating" nonsense