Agreed this would be a good option to have. The question is how to do it without having a morass of nasty nested if-defs. Note that portably getting alignment out of malloc() alone is already ugly and not as simple a code as I would like. To simplify things we could always require 16 byte alignment everywhere? But is that a desirable? Barry On Nov 14, 2009, at 12:43 PM, Jed Brown wrote:
Barry Smith wrote:
On Nov 14, 2009, at 11:28 AM, Jed Brown wrote:
Barry Smith wrote:
Good point, I have removed it.
I put it in because I wanted an easy way to test that PETSc double arrays are always 8 byte aligned (and the unaligned struct values were giving me lots of false alarms).
A related issue is PetscMallocN which (in optimized mode) gives unaligned arrays even if malloc always returns aligned memory. Consider
PetscMalloc2(3,PetscInt,&ai,3,PetscScalar,&a);
This call is illegal. You are required to pass the longest aligned arrays first leading the shortest. Hence The PetscScalar should be before the PetscInt.
The debug mode should check that this requirement is satisfied; it currently does not check anything.
If nothing ever checks and the docs don't specify, it's valid.
In the real world when any of these beasts can be 32 bit or 64 bit one cannot always put them in the right order; but for now they should be ordered, PetscScalar, pointer, PetscInt
What advantage does this have over just aligning all the pointers (even to 16-byte to enable movapd and prevent many loads across a cacheline split, see http://x264dev.multimedia.cx/?p=8)? The arithmetic and few wasted bytes is trivial compared to the cost of the allocation, so I don't see a reason not to.
Jed
participants (1)
-
Barry Smith