Hacker News Reader

Comment by Thaxll | Hacker News Reader

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

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.)

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.

Now that you mention it, I guess you're right. Even XNA would be bad if you're pushing the limits of the machine.

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..

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.

Deallocation chains can cause pauses in reference-counted systems.

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.

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.

You cannot have both deterministically-freeing GC and GC without arbitrarily-long pauses. That's kind of a given.

> Why do people assume that cleanup in reference counting has to be synchronous?

It doesn't, but it most real-world implementations of RC it is.

All that extra logic sounds like its approaching garbage collector territory... The more you massage it, the closer it becomes.

To be fair: reference counting is a garbage collector.

Technically it does, but only for handling reference cycles where the reference counter falls apart.

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).

Reply on news.ycombinator.com