The pre-allocation setting, is that just for CSV and prt loaders? Or do I also have to add in the number of particles from PRT loaders?
Thanks,
B.
The pre-allocation setting specifies the total amount of particles you expect to have at render time. This is the sum of all renderable PRT Loaders, PRT Volumes, Particle Flows, Thinking Particles objects, etc. It doesn’t really matter if this amount is accurate, we tend to figure out exactly how much memory we have to spare then specify that amount in particles.
Here is some deeper background info:
In the beginning, the Allocation settings were added because we noticed a significant slowdown with PRT Volumes and such. So we allowed the explit specification of the total memory to allocate and got a huge speedup.
But then we looked closer and discovered that the problem wasn’t just in the fact that the PRT Volume does not know its expected count, but in an actual bug in the memory management. It was SUPPOSED to double the memory each time the previous allocation was used up, but it was growing by a much smaller step, causing all the slowdowns.
So we fixed that bug and now the memory management works as expected. Thus, if you disable the explicit Pre-Allocation, the PRT Volumes will render almost as fast, but the memory usage graph in Task Manager will be quite different.
If you don’t use pre-allocation and try to generate, say, 100MP, you can see the memory starting low, then increasing to three times the previous amount, then dropping quickly to the previous amount times two (this is because the previous stream of size A is being copied in memory to size 2A resulting in two streams with total size of 3A, and then the old one of size A is being released). After several iterations, all the particles end up in memory and the usage is generally a bit more than was really needed because the last step was quite big. Due to the memory spikes during the copying of the stream, it is quite possible that the total available memory limit could be reached causing swapping. Also, since the memory is allocated a couple of times and streams a copied around, this adds a couple of seconds overhead to the total render time.
When you do use Pre-Allocation, if you expect 100MP, you can tell Krakatoa to reserve memory for EXACTLY that count, and just ONCE. Thus, there is no growth, no copying and no double-memory spikes in this process - the memory is allocated in the beginning and all particles just go in it. Now if you happen to generate 101MP, the memory will be doubled according to the previous scheme to provide space for the 1MP excess particles automatically, with all the related overhead, copying and spiking.
This is why we decided to leave the Pre-Allocation option in Beta 3 - if you have an idea of the particle count to be expected, or know the limits of your workstation (say, you have 32 GB and want to always allocate 16 GB for particles regardless of the actual count), you can use the Pre-Allocation and get the best performance and memory usage within the desired limits. Otherwise, you will get only slightly slower performance and the memory allocation will automaticly adapt to the needs of the systems.
Thanks for the info.
slightly off-topic, have you looked at the new move constructor (&&) in c++0x? I might use the STL more now. And while I’m on random alloc chat. Have you tried nedMalloc nedprod.com/programs/portable/nedmalloc/
C++0X has/had lots of cool things. I miss concepts already. The move constructor looks pretty sweet, and I’m very ready for the auto keyword to be re-purposed. The only thing now is to wait for the standard to be finished, and Microsoft to write a compliant compiler. I don’t have high hopes for seeing anything usable until 2011 though.
EDIT: Microsoft’s site is pretty worthless for feature information, but it looks like most of this stuff made it into VS2010. Yay! http://msdn.microsoft.com/en-us/library/dd465215%28VS.100%29.aspx
they ditched the .ncb file for a new intellisense system and new project/build system. I’m going to try it just for that. And lambda’s in c++ woot!