Hacker News Reader

Comment by dfox | Hacker News Reader

There are languages whose execution model inherently produce large amounts of short-lived objects as sideffect of execution of some code with no explicit allocations, Smalltalk and Scheme with call/cc are probably best examples with Python being comparable, albeit for different reasons.

On the other hand, very often it's convenient to just return some freshly allocated object out of function invocation (non-obvious, but trivial example: string), which is why the generational hypothesis tends to hold for almost any language.

View on HN

Sure, but it's also worth pointing out that the class of programs that behave this way is the class of programs that are inefficient to begin with.

If you handle strings, and you are copying and freeing strings all the time, that's just slow code.

And it's not the case that GC makes the slow code faster... it's that certain techniques enable GC to not fail catastrophically on slow code.

It's a little bit disturbing that folks are ready to extrapolate this to some kind of universal rule.

In a high-end video game, for example, we hardly allocate anything short-term at runtime. The whole program is architected to avoid it. When we allocate, it tends to be things with medium-to-long-term life (texture maps, sound effects, render targets, whatever) so a generational system is useless there. In fact we don't use GC on these kinds of things at all, because we also need to control exactly when they are deallocated so we can put something in their place, because memory is limited.

You have things that only live for a short while do you not? Object pooling, stack allocation, etc are designed to solve that problem as I understand it.

While the objects in the pools or stacks may seem transient (on your screen for only a few moments), one simple technique is to only allocate those objects at load time and then flip them in an "on" or "off" state during gameplay. That way you're not doing any real allocation after your game space has loaded.

No, those are only seen as "ways to solve the problem" by the functional-style programmers who created the problem in the first place.

Stack allocation is what your computer is built from the ground up to do. It is not some kind of workaround or optimization, it is how software was originally designed to work.

Game engines are strongly generational too, you just don't notice because the short lived allocations are all put on the stack by the developer.

I think at this point you are abusing terminology such that it's meaningless.

I am not just talking about putting copies of things on the stack, but having few copies to begin with, etc.

Reply on news.ycombinator.com