5 ms·

Is that possible to make a realtime gameserver with the actual GC?

by Thaxll 12y ago

masklinn 12y ago
Depends what you mean by "realtime". Pauses of 10ms is still 60% of a frame budget potentially every 3 frames. You're probably not simulating the game at 60fps, but it's worth about 2000 miles of network delay[0]. All in all, depends whether you're serving for a turn-by-turn roguelike, an RTS or an FPS. Won't be an issue for the first one, may not be for the second one, the latter though... [0] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html
- marvy 12y ago
  I smile every time I read that story. I'm up-voting for the link alone. (But yeah, it really sounds like they didn't have games in mind when they designed Go.)
  - gillianseed 12y ago
    Well 'games' is a quite wide concept, there's been a ton of games released through XNA which used a 'stop the world' garbage collector until late in it's existence IIRC. So there's no reason why your typical indie style game would not be written in Go, but of course if you want to write AAA style 'push the boundaries of realtime graphics and physics', Go or any other garbage collected language is not a very likely candidate.
    - marvy 12y ago
      Now that you mention it, I guess you're right. Even XNA would be bad if you're pushing the limits of the machine.
ashleyw 12y ago
I tried, but stopping the world hurts. Reusing stacks helps, but you're fighting the language from the very beginning. It wouldn't be a wise choice for even soft real-time IMO, you may as well just use Python or Ruby if you don't care about stopping the world..
- Game_Ender 12y ago
  Python doesn't have a STW garbage collector, it uses deterministic reference counting. So while slower than go you won't have random pauses in your server processes due to memory management.
  - pcwalton 12y ago
    Deallocation chains can cause pauses in reference-counted systems.
    - TheLoneWolfling 12y ago
      Why do people assume that cleanup in reference counting has to be synchronous? You can deal with deallocation chains in reference-counted systems without having arbitrarily-long pauses. You keep a stack of <pointers to items to be removed + current child index in item>. When something's reference count goes to 0, push it onto the stack, with a child index of zero. Every so often, pop the last item off of the stack, if (the child index is after the last child) {deallocate the memory}, else {decrement the reference count of the child of the object indexed by the child index, pushing that onto the stack with a child index of 0 if the child is now dead, and push it back onto the stack with an incremented child index}. You can do any/all of this in batches.
      - theseoafs 12y ago
        It's well-known that you can incrementally free objects that are known to be garbage but it's not usually implemented for reference counting since it's not typically seen as a good fit because it undermines the advantages of reference counting a bit: now, objects aren't freed deterministically when they become garbage (that is objects are destroyed at unpredictable times) and you're now introducing unpredictable pauses into the language runtime to free garbage objects (short though those pauses may be). Maintaining the free stack also adds overhead. It's just not a very good fit.
        12y ago
rm445 12y ago
In my very limited understanding, hard real time systems collect memory in a fashion _more_ like this than previously. The idea is to use a ticky-tocky garbage collection system that always takes a certain amount of time ('tick') but guarantees the system enough usable time ('tock') to respond to the outside world in an appropriate fashion. The point, (again note I'm not an expert in this stuff) is that there's no such thing as an infinitely responsive real-time system - even hardwired analogue electronics, or a program running entirely in CPU cache, have a response time. So realtime always means that the system responds acceptably quickly for the application, without slowing down. Now as to how this applies to games, obviously a 10 ms pause is not a great help for updating a 60 Hz game every 16 ms. But for some lower speeds it could reduce latency and give an overall smoother feel to networked gaming. A couple of other posters on this thread have already mentioned tricks to get around this, if multiple processes can share the load and gracefully garbage-collect. But on the whole it seems like offering some configurability would make Go more versatile. In the extreme you might want to turn off the GC and make use of a manual free-type function. (I gather the Go developers oppose this on philosophical grounds).

Is that possible to make a realtime gameserver with the actual GC?

by Thaxll 12y ago

Is that possible to make a realtime gameserver with the actual GC?

Depends what you mean by "realtime". Pauses of 10ms is still 60% of a frame budget potentially every 3 frames. You're probably not simulating the game at 60fps, but it's worth about 2000 miles of network delay[0]. All in all, depends whether you're serving for a turn-by-turn roguelike, an RTS or an FPS. Won't be an issue for the first one, may not be for the second one, the latter though... [0] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html

marvy 12y ago
I smile every time I read that story. I'm up-voting for the link alone. (But yeah, it really sounds like they didn't have games in mind when they designed Go.)
- gillianseed 12y ago
  Well 'games' is a quite wide concept, there's been a ton of games released through XNA which used a 'stop the world' garbage collector until late in it's existence IIRC. So there's no reason why your typical indie style game would not be written in Go, but of course if you want to write AAA style 'push the boundaries of realtime graphics and physics', Go or any other garbage collected language is not a very likely candidate.
  - marvy 12y ago
    Now that you mention it, I guess you're right. Even XNA would be bad if you're pushing the limits of the machine.

ashleyw 12y ago

I tried, but stopping the world hurts. Reusing stacks helps, but you're fighting the language from the very beginning. It wouldn't be a wise choice for even soft real-time IMO, you may as well just use Python or Ruby if you don't care about stopping the world..

Game_Ender 12y ago
Python doesn't have a STW garbage collector, it uses deterministic reference counting. So while slower than go you won't have random pauses in your server processes due to memory management.
- pcwalton 12y ago
  Deallocation chains can cause pauses in reference-counted systems.
  - TheLoneWolfling 12y ago
    Why do people assume that cleanup in reference counting has to be synchronous? You can deal with deallocation chains in reference-counted systems without having arbitrarily-long pauses. You keep a stack of <pointers to items to be removed + current child index in item>. When something's reference count goes to 0, push it onto the stack, with a child index of zero. Every so often, pop the last item off of the stack, if (the child index is after the last child) {deallocate the memory}, else {decrement the reference count of the child of the object indexed by the child index, pushing that onto the stack with a child index of 0 if the child is now dead, and push it back onto the stack with an incremented child index}. You can do any/all of this in batches.
    - theseoafs 12y ago
      It's well-known that you can incrementally free objects that are known to be garbage but it's not usually implemented for reference counting since it's not typically seen as a good fit because it undermines the advantages of reference counting a bit: now, objects aren't freed deterministically when they become garbage (that is objects are destroyed at unpredictable times) and you're now introducing unpredictable pauses into the language runtime to free garbage objects (short though those pauses may be). Maintaining the free stack also adds overhead. It's just not a very good fit.
      - 12y ago

rm445 12y ago

In my very limited understanding, hard real time systems collect memory in a fashion _more_ like this than previously. The idea is to use a ticky-tocky garbage collection system that always takes a certain amount of time ('tick') but guarantees the system enough usable time ('tock') to respond to the outside world in an appropriate fashion. The point, (again note I'm not an expert in this stuff) is that there's no such thing as an infinitely responsive real-time system - even hardwired analogue electronics, or a program running entirely in CPU cache, have a response time. So realtime always means that the system responds acceptably quickly for the application, without slowing down. Now as to how this applies to games, obviously a 10 ms pause is not a great help for updating a 60 Hz game every 16 ms. But for some lower speeds it could reduce latency and give an overall smoother feel to networked gaming. A couple of other posters on this thread have already mentioned tricks to get around this, if multiple processes can share the load and gracefully garbage-collect. But on the whole it seems like offering some configurability would make Go more versatile. In the extreme you might want to turn off the GC and make use of a manual free-type function. (I gather the Go developers oppose this on philosophical grounds).