5 ms·

Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictabl

Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.

TylerE 13y ago
When latency matters, just use pool allocation, which makes the GC irrelevant.
- pcwalton 13y ago
  Pools are still traced.
  - spullara 13y ago
    If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.
    - deleted 13y ago
      [deleted]
    - klausa 13y ago
      Targeting 30fps, you have 33ms to render whole frame. Losing 20 ms of that to GC would make things… challenging. And if you're targeting 60fps, that's 16ms. Stop the world for 20ms, and you've missed 1 and 1/4 of a frame.
      - spullara 13y ago
        There are concurrent collectors that do not stop the world (e.g. Azul's) that you might want to look at for game development.
- fhd2 13y ago
  That's how people manage to make games despite GC, but I always thought it's a huge hack, having been there. If all you do with your GC is fight it, is it actually a good idea to have it? One thing that makes me excited about Rust is that GC is optional.
usea 13y ago
I don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations. See: Minecraft, Terraria, Magicka, AI War, and many more.
- charliesome 13y ago
  The JVM and CLR both have generational garbage collectors, which reduces the impact of most GC pauses quite significantly. Go's GC on the other hand is non-generational, which means every GC pause must perform a full scan of all objects in the system.
  - usea 13y ago
    Sorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.
    - charliesome 13y ago
      I've updated my post, sorry for the confusion!
  - seanmcdirmid 13y ago
    Is there a reason why future work on Go's runtime couldn't fix this problem?
    - AndreasFrom 13y ago
      Not at all, it just takes work.
    - sanxiyn 13y ago
      I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."
gillianseed 13y ago
I disagree with your 'wholly unsuitable', I came across this game engine (Garage engine) written in Go which certainly doesn't jitter due to the garbage collector. http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=BMRlY9dFVLg https://github.com/vova616/GarageEngine https://github.com/vova616/GarageEngine So I say your statement is exagerrated, certainly stop-the-world garbage collectors isn't ideal for games, but it's not 'wholly unsuitable' as long as the gc sweeps aren't costly enough to impact consistent framerate. Had they been 'wholly unsuitable' then the XNA platform would have been dead upon arrival.
Tichy 13y ago
Just avoid producing too much garbage then?

Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.

TylerE 13y ago

When latency matters, just use pool allocation, which makes the GC irrelevant.

pcwalton 13y ago
Pools are still traced.
- spullara 13y ago
  If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.
  - deleted 13y ago
    [deleted]
  - klausa 13y ago
    Targeting 30fps, you have 33ms to render whole frame. Losing 20 ms of that to GC would make things… challenging. And if you're targeting 60fps, that's 16ms. Stop the world for 20ms, and you've missed 1 and 1/4 of a frame.
    - spullara 13y ago
      There are concurrent collectors that do not stop the world (e.g. Azul's) that you might want to look at for game development.
fhd2 13y ago
That's how people manage to make games despite GC, but I always thought it's a huge hack, having been there. If all you do with your GC is fight it, is it actually a good idea to have it? One thing that makes me excited about Rust is that GC is optional.

usea 13y ago

I don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations. See: Minecraft, Terraria, Magicka, AI War, and many more.

charliesome 13y ago
The JVM and CLR both have generational garbage collectors, which reduces the impact of most GC pauses quite significantly. Go's GC on the other hand is non-generational, which means every GC pause must perform a full scan of all objects in the system.
- usea 13y ago
  Sorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.
  - charliesome 13y ago
    I've updated my post, sorry for the confusion!
- seanmcdirmid 13y ago
  Is there a reason why future work on Go's runtime couldn't fix this problem?
  - AndreasFrom 13y ago
    Not at all, it just takes work.
  - sanxiyn 13y ago
    I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."

gillianseed 13y ago

I disagree with your 'wholly unsuitable', I came across this game engine (Garage engine) written in Go which certainly doesn't jitter due to the garbage collector. http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=BMRlY9dFVLg https://github.com/vova616/GarageEngine https://github.com/vova616/GarageEngine So I say your statement is exagerrated, certainly stop-the-world garbage collectors isn't ideal for games, but it's not 'wholly unsuitable' as long as the gc sweeps aren't costly enough to impact consistent framerate. Had they been 'wholly unsuitable' then the XNA platform would have been dead upon arrival.

Tichy 13y ago

Just avoid producing too much garbage then?