Hacker News Reader

Comment by bob1029 | Hacker News Reader

I'd argue that incremental GC isn't actually that bad. The lifetime of an object can be more confounding that it might seem at first glance. It is really easy for a game design decision to alter these lifetimes arbitrarily. Even if you know something is going to live for one frame only, it's not like you are surrendering the entire kingdom if you fail to exploit the optimization opportunity.

There are a lot of other problems to worry about in game dev. Manual memory management is a luxury mostly exclusive to larger studios. Solo developers won't make to the actual runway if they try to fight these kinds of technical battles on principled terms. You often need a lot of samples (paying customers / large QA team) to prove these custom schemes are viable. For better or worse, the cranky old GC might be the lowest risk option. A few late frames is a hell of a lot less disruptive to the gamer than a crash.

View on HN

You're probably right, in practice it would be just fine.

That said if you look at a lot of the basic GC approaches you end up either moving all the allocated and live objects, or running through a mark & sweep dance which gives you holes in your allocation region - and causes problems with fragmentation.

Choosing the right kind of GC, knowing your constraints, could probably sidestep these problems, but there seems to be nothing obvious with the simple two-headed bump-allocator decribed in the post, so long as the lifecycles don't change over time - ruining the simplicity of the arena-based approach.

It depends a lot on the person I guess. But I'd gladly trade, let's say hourly crashes, for great frametimes.

GC generally only results in the occasional missed frame, it doesn't negatively impact overall frametimes in a meaningful way if it's implemented correctly. GC malloc() and free() are both fast.

I think the average player would not appreciate hourly crashes, especially in games without aggressive autosave - that potentially means having to replay 10+ minutes worth of gameplay on a regular basis because your timing was bad, when you consider how a typical game is built. You could compensate for this in some game types I guess, like in a competitive FPS you'd restart the client software between matches and hope a match never lasts long enough to crash. But that's no substitute for real robustness, IMO.

Inconsistent frame times tend to feel worse than just lower frametimes, on the whole. There's a reason a lot of benchmarking has started highlighting the 1% lows.

I certainly would not appreciate hourly crashes, don't get me wrong. But inconstant frame pacing makes me queasy. It's not low frametimes that is the issue, it's the inconsistency.

Hitches are much less an issue with modern GC.

The real drawback to GC is the inability to estimate your peak memory consumption

Many usecases cannot afford allocations that move

Reply on news.ycombinator.com