Hlrad
KungFuDiscoMonkey
Creator of ns_altair日本福岡県 Join Date: 2003-03-15 Member: 14555Members, NS1 Playtester, Reinforced - Onos
Creator of ns_altair日本福岡県 Join Date: 2003-03-15 Member: 14555Members, NS1 Playtester, Reinforced - Onos
<div class="IPBDescription">Question for Cagey</div> I understand that HLRAD is very memory intensive and uses large ammounts of RAM and Virtual Memory but it seams to eat into a lot of Virtual Memory even when there is still a fair ammount of system memory available. I was curious why this might be.
Maybe you could enlighten us to some of how HLRAD works the way it does.
Maybe you could enlighten us to some of how HLRAD works the way it does.
Comments
Maybe you could enlighten us to some of how HLRAD works the way it does.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The use of Virtual Memory while there's still RAM available sounds like Windows dropping the ball when it's swapping pagefiles. I'm almost positive the tools aren't trying to do any custom pagefile management that would cause this to happen.
There are, however, two issues with HLRAD memory management that are fundamental enough to be major rewrites:
1) HLRAD (and all of the other tools) frequently allocate static arrays for storage -- in English, this means that instead of requesting memory each time more is needed, each stage of ZHLT actually grabs enough memory at program startup to hold the maximum number of items allowed.
So, for instance, HLCSG asks for memory for 64K planes before a single plane is actually being used by the program.
Static allocation makes memory errors far less likely and results in less time spent managing memory, but it often means taking up huge chunks of memory that aren't actually used. If you compile a one room box, the tools still reserve enough memory for 64K planes, 32K leaves, 32K nodes, 64K clipnodes, etc.
2) HLRAD ends up storing a lot of extra garbage that is only used 1% of the time. Spotlight information, for example, is stored for every light source including light bounces -- it's a small amount of memory per light that adds up very quickly as the number of bounced lights approaches the hundreds of thousands for large maps. It would have been better to store the extra information only when necessary. There are similar wastes of space for other data structures.
Do you know of a way to get this to work a better or is that something Microsoft has to fix?
My experience has been that turning off virtual memory makes your computer screaming fast.... until you use up all the ram, at which point it locks up and you have to reboot. Never said this was the ideal solution but I think you should be able to tweak it through a compile. Nice part is that if you have two boxes you could run the backup this way for a compile and it would work that much faster on it.
Messing with virtual memory can be a big problem though. Mem hog that winXP is I wouldn't recommend even thinking about turning it off on a system with less than 512 megs. AFAIK you do have to make it through a successful reboot with the virtual memory disabled. If your comp can't manage that you could/could not be in a big mess because you have to get windows back up in some fashion to re-enable virtual mem.
I have also heard of registry tweaks that will force windows to utilize physical memory more. Don't know what they are off the top of my head, although I think the ones that I remember are for win2k. Either way playing with the registry is a good way to foobar windows real bad real fast. If you're really interested about it try starting at www.google.com
If you can't find it on that amount of information you should probably just leave things alone.