3 ms·

I don't think register allocation is a great analogy since it is largely a "solved problem" - there are well known techniques that allow compilers to do as good

I don't think register allocation is a great analogy since it is largely a "solved problem" - there are well known techniques that allow compilers to do as good or better job of it than a programmer in most situations. This is not yet true for memory management. You give "writing a game" as an example where memory management is not the actual problem. Games however often care a lot about performance and achieving good performance is part of the actual problem you're solving. For many games projects on current hardware you won't be able to solve the performance problem without thinking about memory allocation and blindly relying on the garbage collector will result in a game that doesn't solve the actual problem of performing adequately on the target hardware.

marvy 8y ago
Sure, register allocation is mostly solved and memory management is far from solved; thus memory management gets far more of the game programmer's attention (or else your game will play at two frames per second, plus occasional longer pauses). But the analogy is otherwise fine: reviews of your game will mention the performance (because it matters), but they will not mention your memory management strategy (because the don't care and may not even know). They will mention the rules, the mechanics, the story, the graphics and music and sound effects. Those are all part of the actual problem. Memory management is an implementation detail. Don't get me wrong: this implementation detail is so vital that it may very well make sense to structure the entire code base around it, but that doesn't mean it's part of the "actual" problem, at least if you use my definition. (See also my other reply in this thread.)