-malign-double

[Barry Smith]

    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
>