5 ms·

Well, congratulations on the bragging rights?! That is magnitudes too long for actual real-time or low latency use. It is squarely in a no-mans-land of applicat

Well, congratulations on the bragging rights?! That is magnitudes too long for actual real-time or low latency use. It is squarely in a no-mans-land of applications where the worst-case is still too much for games or sound but all other uses didn't care very much for GC pause in the first place.

throwaway2016a 10y ago
That's great... but 1. A 18 gigabyte heap puts it magnitudes larger than a game, presumably performance is better for smaller apps 2. I write web application servers and I very much care about GC latency
hamandcheese 10y ago
For gaming, assuming a target of 60fps, a 1ms GC pause still leaves 15.6ms to render the next frame. Which is 93% of the available time.
- socmag 10y ago
  Or even better.. I've written 3D/Game Engines engines in languages with GC based runtimes that run at 1500fps with no GC pauses. How to do it? Easy... don't create garbage! So yes, it is doable. PITA but doable Certainly helps if you have a good generational GC. That said, if you can force a compaction once a frame and it's pretty stable at a millisecond, I guess that's more than fine for a lot of stuff.
  - nameless912 10y ago
    Exactly this. In Java, it's definitely possible to almost completely avoid garbage, and the GC is tunable enough that you could consistently have the GC run once per frame, which then makes it just a normal part of the frame timing if you have a general idea of what is being created. Object pooling is magical, yo. I imagine in Golang, this would only get easier as the pauses are super short and I feel more control over the memory allocation (whether this is true or not is an open question).
    - socmag 10y ago
      Yes, definitely a lot of object pooling! :+1: Use POD's to store data ...and use "int's" instead of references. Those index into tables of the objects. These will be opaque to the GC so it doesn't have to follow any pointers.
      - nameless912 10y ago
        POD's?
        socmag 10y ago
        Oops sorry.. Plain Old Data structures. Specifically I mean data structures that contain only basic types and no reference types or pointers. https://en.m.wikipedia.org/wiki/Passive_data_structure https://en.m.wikipedia.org/wiki/Passive_data_structure Another important trick is to use structures of arrays, rather than arrays of structures. Well that kind of depends on the use case, but you can get huge wins in memory access if you need to scan only one field. Same tradeoff as Row vs Column Databases.
- mewse 10y ago
  That isn't really how it works. The catastrophic problem with GC for games isn't the specific amount of time it takes up, it's that it's a periodic task; it perhaps happens once every few seconds, or even less. Which means that if you're going to have GC in your game, then you're always going to be discarding some percentage of the available CPU time so that you can survive the occasional frame where the GC runs. (or else you're having frame rate hiccups every time it runs) Nobody in the AAA industry wants to say "Okay, lets only use 90% of the hardware's capabilities, so that those few frames in which the GC is going to run, it won't cause a frame rate hitch"; we instead engage in extraordinary (some might say 'heroic', others might say 'foolhardy') amounts of engineering effort to remove those periodic expenses, so we can move ever-closer to consistent 100% usage of the available hardware capabilities. Sometimes that means "we're going to build this in a more difficult language which doesn't support GC", sometimes that means "we're going to figure out how to build this in this GC-enabled language without doing anything that would accidentally invoke the GC", and sometimes that means "we're going to figure out how to provide our own GC implementation which operates progressively, only spending a budgeted amount of CPU time per frame". Personally, I skew toward that first solution. But I'm old-fashioned that way. :) (caveat: I haven't actually worked on a 'AAA' game in the current console generation, and the majority of my industry experience was during the PS2 era. Stuff might have changed in the last few years, though I imagine that the basic principles still hold.)
todd8 10y ago
I'm just curious, but what are realistic goals for games and sound? I've never programmed professionally in those areas.
- shermanyo 10y ago
  Games tend to target 60fps based on current displays, generally based on the vertical sync rate. (some monitors are 144Hz, for example) 60fps is roughly 16ms, for reference. Audio is different, it's often about round trip latency (eg. from the time the sound is made, to when it is heard back) and has a few additional issues to consider. Eg. there can be phasing issues where one signal cancels out or amplifies another. This is controlled by varying the buffer sizes, but issues can still arise due to processing latency. If the output buffer falls behind you'll hear pops as the speakers cut out. A lot of DSP code is written to be lock-free by allocating vars when initializing so no memory allocations actually occur during updates. There are a couple great youtube talks on the subject. (look at the JUCE and CppCon channels)
pjmlp 10y ago
Not everyone is doing AAA games, and thankfully so, because in 2016 many of those are just pretty graphics with no real content. Also I remember the days when any serious game developer would use Assembly, C and Pascal were only used by indie developers. Times change.

throwaway2016a 10y ago

That's great... but 1. A 18 gigabyte heap puts it magnitudes larger than a game, presumably performance is better for smaller apps 2. I write web application servers and I very much care about GC latency

hamandcheese 10y ago

For gaming, assuming a target of 60fps, a 1ms GC pause still leaves 15.6ms to render the next frame. Which is 93% of the available time.

socmag 10y ago
Or even better.. I've written 3D/Game Engines engines in languages with GC based runtimes that run at 1500fps with no GC pauses. How to do it? Easy... don't create garbage! So yes, it is doable. PITA but doable Certainly helps if you have a good generational GC. That said, if you can force a compaction once a frame and it's pretty stable at a millisecond, I guess that's more than fine for a lot of stuff.
- nameless912 10y ago
  Exactly this. In Java, it's definitely possible to almost completely avoid garbage, and the GC is tunable enough that you could consistently have the GC run once per frame, which then makes it just a normal part of the frame timing if you have a general idea of what is being created. Object pooling is magical, yo. I imagine in Golang, this would only get easier as the pauses are super short and I feel more control over the memory allocation (whether this is true or not is an open question).
  - socmag 10y ago
    Yes, definitely a lot of object pooling! :+1: Use POD's to store data ...and use "int's" instead of references. Those index into tables of the objects. These will be opaque to the GC so it doesn't have to follow any pointers.
    - nameless912 10y ago
      POD's?
      - socmag 10y ago
        Oops sorry.. Plain Old Data structures. Specifically I mean data structures that contain only basic types and no reference types or pointers. https://en.m.wikipedia.org/wiki/Passive_data_structure https://en.m.wikipedia.org/wiki/Passive_data_structure Another important trick is to use structures of arrays, rather than arrays of structures. Well that kind of depends on the use case, but you can get huge wins in memory access if you need to scan only one field. Same tradeoff as Row vs Column Databases.
mewse 10y ago
That isn't really how it works. The catastrophic problem with GC for games isn't the specific amount of time it takes up, it's that it's a periodic task; it perhaps happens once every few seconds, or even less. Which means that if you're going to have GC in your game, then you're always going to be discarding some percentage of the available CPU time so that you can survive the occasional frame where the GC runs. (or else you're having frame rate hiccups every time it runs) Nobody in the AAA industry wants to say "Okay, lets only use 90% of the hardware's capabilities, so that those few frames in which the GC is going to run, it won't cause a frame rate hitch"; we instead engage in extraordinary (some might say 'heroic', others might say 'foolhardy') amounts of engineering effort to remove those periodic expenses, so we can move ever-closer to consistent 100% usage of the available hardware capabilities. Sometimes that means "we're going to build this in a more difficult language which doesn't support GC", sometimes that means "we're going to figure out how to build this in this GC-enabled language without doing anything that would accidentally invoke the GC", and sometimes that means "we're going to figure out how to provide our own GC implementation which operates progressively, only spending a budgeted amount of CPU time per frame". Personally, I skew toward that first solution. But I'm old-fashioned that way. :) (caveat: I haven't actually worked on a 'AAA' game in the current console generation, and the majority of my industry experience was during the PS2 era. Stuff might have changed in the last few years, though I imagine that the basic principles still hold.)

todd8 10y ago

I'm just curious, but what are realistic goals for games and sound? I've never programmed professionally in those areas.

shermanyo 10y ago
Games tend to target 60fps based on current displays, generally based on the vertical sync rate. (some monitors are 144Hz, for example) 60fps is roughly 16ms, for reference. Audio is different, it's often about round trip latency (eg. from the time the sound is made, to when it is heard back) and has a few additional issues to consider. Eg. there can be phasing issues where one signal cancels out or amplifies another. This is controlled by varying the buffer sizes, but issues can still arise due to processing latency. If the output buffer falls behind you'll hear pops as the speakers cut out. A lot of DSP code is written to be lock-free by allocating vars when initializing so no memory allocations actually occur during updates. There are a couple great youtube talks on the subject. (look at the JUCE and CppCon channels)

pjmlp 10y ago

Not everyone is doing AAA games, and thankfully so, because in 2016 many of those are just pretty graphics with no real content. Also I remember the days when any serious game developer would use Assembly, C and Pascal were only used by indie developers. Times change.