4 ms·

> Also hard upper limits on GC time are very helpful for those cases where allocations can't be reduced any further Yes, but 10ms is too long to be useful for

by tomlu 12y ago

> Also hard upper limits on GC time are very helpful for those cases where allocations can't be reduced any further Yes, but 10ms is too long to be useful for games. I'd rather take 1ms every frame than 10ms sometimes.

enneff 12y ago
10ms is an upper bound. Games typically don't do a lot of allocations during gameplay, so it's unlikely that Go's GC would be an issue for most gaming applications. And, as I mention whenever this comes up, Minecraft is written in Java and suffers from huge GC pauses, yet it's one of the most successful games of the last decade.
- Havvy 12y ago
  And yet the GC pauses are noticable and annoying. It's not game-breaking because Minecraft is just that good, but I doubt it'd work well for other games.
  - enneff 12y ago
    I brought up Minecraft as proof that gamers are willing to tolerate the occasional bit of lag. And, honestly, I haven't played an AAA game that doesn't lag out and drop frames from time to time. To return to the topic at hand: 60fps is 16ms per frame. The proposed GC would achieve sub-10ms pauses. So, worst case you might drop the odd frame. To assume that Go is unsuitable for games because of garbage collection is to ignore reality.
eloff 12y ago
I don't buy that argument. Lua has a much worse STW garbage collector and it's commonly used in games. Furthermore with games you can do tricks like allocating out of an arena with bump pointers and then resetting the pointer at the end of the frame. Lots of games are developed with JVM, .NET, or Lua. GC doesn't seem to be a show stopper for them, you just have to be smart about allocations.
- jblow 12y ago
  Lots of low-end, non-premium-experience games are made with those things. And e.g. games that use Lua usually only use it for high-level gameplay logic, i.e. most of the running code is in C++ or something. And yes, it's a problem. See the other comments here about VR. With VR you want to render at 90 frames per second, in other words, you get 11 milliseconds to draw the scene twice (once for each eye). That is 5.5 milliseconds to draw the scene. If you pause and miss the frame deadline, it induces nausea in the user. But this comment drives me up the wall: "GC doesn't seem to be a show stopper for them, you just have to be smart about allocations..." The whole point of GC is to create a situation where you don't have to think about allocations! If you have to think about allocations, GC has failed to do its job. This is obvious, yet there are all these people walking around with some kind of GC Stockholm Syndrome. So now you are trapped in a situation where not only do you have to think about allocations, and optimize them down, etc, etc, but you have also lost the low-level control you get in a non-GC'd language, and have given up the ability to deliver a solid experience. Bad trade.
  - enneff 12y ago
    > The whole point of GC is to create a situation where you don't have to think about allocations! Nope. The point of GC is memory safety. GC also means you don't have to think about freeing memory, which is important in concurrent systems. But even if GC was about "not thinking about allocations", what's bad about only having to think about allocations when it's important? Code clarity trumps performance, except at bottlenecks.
    - jblow 12y ago
      Well, you're being a bit revisionist. You can get memory safety without GC, and a number of GC'd systems do not provide memory safety. If you think that, for concurrent systems, it is a good idea to let deallocations pile up until some future time at which a lot of work has to be done to rediscover them, and during this discovery process ALL THREADS ARE FROZEN, then you have a different definition of concurrency than I do. Or something. If you want to know about code clarity, then understanding what your program does with memory, and expressing that clearly in code rather than trying to sweep it under the rug, is really good for clarity. Try it sometime.
pshc 12y ago
I don't know why you're getting downvoted. Variance is terrible for games. We're at the cusp of a VR renaissance where frames are ideally rendered every 11ms (90fps), and VR is way broader than video games! STW is basically a non-starter in this environment.

by tomlu 12y ago

enneff 12y ago

10ms is an upper bound. Games typically don't do a lot of allocations during gameplay, so it's unlikely that Go's GC would be an issue for most gaming applications. And, as I mention whenever this comes up, Minecraft is written in Java and suffers from huge GC pauses, yet it's one of the most successful games of the last decade.

Havvy 12y ago
And yet the GC pauses are noticable and annoying. It's not game-breaking because Minecraft is just that good, but I doubt it'd work well for other games.
- enneff 12y ago
  I brought up Minecraft as proof that gamers are willing to tolerate the occasional bit of lag. And, honestly, I haven't played an AAA game that doesn't lag out and drop frames from time to time. To return to the topic at hand: 60fps is 16ms per frame. The proposed GC would achieve sub-10ms pauses. So, worst case you might drop the odd frame. To assume that Go is unsuitable for games because of garbage collection is to ignore reality.

eloff 12y ago

I don't buy that argument. Lua has a much worse STW garbage collector and it's commonly used in games. Furthermore with games you can do tricks like allocating out of an arena with bump pointers and then resetting the pointer at the end of the frame. Lots of games are developed with JVM, .NET, or Lua. GC doesn't seem to be a show stopper for them, you just have to be smart about allocations.

jblow 12y ago
Lots of low-end, non-premium-experience games are made with those things. And e.g. games that use Lua usually only use it for high-level gameplay logic, i.e. most of the running code is in C++ or something. And yes, it's a problem. See the other comments here about VR. With VR you want to render at 90 frames per second, in other words, you get 11 milliseconds to draw the scene twice (once for each eye). That is 5.5 milliseconds to draw the scene. If you pause and miss the frame deadline, it induces nausea in the user. But this comment drives me up the wall: "GC doesn't seem to be a show stopper for them, you just have to be smart about allocations..." The whole point of GC is to create a situation where you don't have to think about allocations! If you have to think about allocations, GC has failed to do its job. This is obvious, yet there are all these people walking around with some kind of GC Stockholm Syndrome. So now you are trapped in a situation where not only do you have to think about allocations, and optimize them down, etc, etc, but you have also lost the low-level control you get in a non-GC'd language, and have given up the ability to deliver a solid experience. Bad trade.
- enneff 12y ago
  > The whole point of GC is to create a situation where you don't have to think about allocations! Nope. The point of GC is memory safety. GC also means you don't have to think about freeing memory, which is important in concurrent systems. But even if GC was about "not thinking about allocations", what's bad about only having to think about allocations when it's important? Code clarity trumps performance, except at bottlenecks.
  - jblow 12y ago
    Well, you're being a bit revisionist. You can get memory safety without GC, and a number of GC'd systems do not provide memory safety. If you think that, for concurrent systems, it is a good idea to let deallocations pile up until some future time at which a lot of work has to be done to rediscover them, and during this discovery process ALL THREADS ARE FROZEN, then you have a different definition of concurrency than I do. Or something. If you want to know about code clarity, then understanding what your program does with memory, and expressing that clearly in code rather than trying to sweep it under the rug, is really good for clarity. Try it sometime.

pshc 12y ago

I don't know why you're getting downvoted. Variance is terrible for games. We're at the cusp of a VR renaissance where frames are ideally rendered every 11ms (90fps), and VR is way broader than video games! STW is basically a non-starter in this environment.