On Mon, May 23, 2011 at 11:48 AM, Roland Haas roland.haas@physics.gatech.edu wrote:
Array padding:
- Erik suggests introducing array padding into Cactus to avoid cache
aliasing issues
- re-use existing but (essentially) unused cctk_lssh for loop boundaries of
i,j,k
- would use cctk_lsh to compute 1D index from i,j,k
- would loop i,j,k using cctk_lssh
- Cactus doc's already say to use cctk_lssh for this
- thorns that are not updated *might* only compute extra unused data for the
"padding" points ** thorns using ghostzones/boundary zones as cctk_lsh-nghostzones/boundary_width might cause problems ** thorns computing in the interior might compute extra data and overwrite ghostzone/boundary information
- would like to have a mechanism to check for errors during runtime
- make padding a runtime parameter in the parameter files
- provide example parfile demonstrating speedup
Regarding array padding, I just found this page http://igoro.com/archive/gallery-of-processor-cache-effects/. Example 5 there documents the effects of padding. If we access (or update) every 512th byte of an array, then this is significantly slower than updating e.g. every 520th byte. This corresponds to making a 2D array slightly larger, so that points in the j direction are separated not by 512, but by 520 bytes.
-erik