As part of a new variant on an algorithm I am using (leaning toward SMP use), I am considering sorting my particles into boxes, by having each box have a particle* []. My only concern is that since the number of particles per box can vary, (average 10 has been known to go as high as 70 in very rare cases), I would need to massively overallocate the pointer arrays. I was thinking probably on the order of 5-10% utilization.
Extreme cases would have on the order of a million of these, so we’re considering half a GB of allocated memory. It’s not a problem in terms of the machines it will run on, but I’m wondering if there’s a performance penalty (caches hate it or something) associated with striding memory that much. (Accessing the first 60 or so bytes out of 500, for example).
I do know to make sure my stride width doesn’t end up being a cache-destroying multiple of 64 though…
I am OK with having it fail in VERY rare cases, as long as this plan buys me enough performance gain to be able to run more successful copies in the same amount of time.
If it’s relevant, this code will mostly be run on Xeon E5620’s, though that will change and I’d rather not do anything architecture-specific.
EDIT: This is comparing N bytes of packed data in contiguous memory to N bytes of data evenly strided over a much larger area of contiguous memory.
If the memory you allocate does not cause swapping, simply having it allocated does not cause any extra overhead.
However, if your algorithm currently packs data points into contiguous memory and your new algorithm spreads that 5%-10% utilization over the entire allocated buffer (unclear from your question if that is the case), you would have quite a few more cache misses accessing memory.
If on the other hand you have one buffer per CPU (and you use contiguous memory), your algorithm may perform better due to reduced opportunity for false sharing.