RE: Fragmentation was RE: [GD-General] Compile times
Brought to you by:
vexxed72
From: Brian H. <bri...@py...> - 2002-12-17 20:43:38
|
> Still, your 2GB of address space will hide fragmentation a lot better > than the PS2s 32MB of address space. Right, but as a matter of discipline (*cough*) I try to code avoiding fragmentation because I never know where one of my, say, puzzle games might be ported (handhelds aren't exactly super highpowered). And on the completely opposite end, I've worked on extremely big games where datasts are routinely several hundred MB chunks. If you're not paying attention in these cases, you may find that you hit some pathological combination of allocs/free that ends up fragmenting things so badly that you're in trouble. And debugging this can often be a huge pain in the ass because if you have a memory tracker it will report a fairly innocent situation (unless your memory tracker also tracks fragmentation). > On the PC, it does not matter so > much if you loose 100k for fragmentation (or even leaks...) when > changing levels. True, you have to start working with VERY large data sets for this to become a serious problem. Alternatively, if you're dealing with a persistent world, this is also a problem with much smaller memory chunks. If you write a small scale persistent game with a long enough up time, you may find that even with no leaks you can't allocate the same stuff you could when the game first started up. That is a ROYAL bitch to find. > But on the PS2, you are going to notice this very > quickly. I've always felt that this area is one of the fundamental > differences between PC programmers and Console programmers. And this is also an area (again) that I feel shows a flaw in C++. When programmers start adopting the mindset of "I don't care about memory, it just works", the cost of finding out that it DOESN'T just work is MONUMENTAL. I've worked on projects like this, where 1GB+ datasets were routinely being considered, along with month+ up times, but ZERO thought was put into how to handle fragmentation. Disaster waiting to happen. Fragmentation is prevalent enough a problem that Objective-C supports "zones" inherently. And any long time programmers will have been bitten by this enough that they probably firmly understand the concept of managing multiple heaps/memory arenas to avoid fragmentation. Of course, you can overload operator new to "fix" this (for particle systems, for example). Until you need multiple arenas for a certain object type. Then, of course, you can work around that too. But after enough work arounds, I just go "You know, I spend more time working around solutions than I do fixing the problems the solutions 'fix'". Crap, when did I get so old that I feel like prefacing everything with "Back in my day..."? =) -Hook |