• bearophile (11/11) Aug 11 2008 Aligned memory for array ops:
• Pete (2/20) Aug 11 2008 Ah. You got there before me :-)
• Don (7/12) Aug 11 2008 Dynamic and static memory allocation of arrays is guaranteed to be
• Wayne Anderson (2/18) Aug 11 2008 I don't understand that. Doesn't it depend on the size of the data type...
• Koroskin Denis (4/31) Aug 11 2008 I think he was talking about ints, floats and doubles since SSE# operate...

bearophile <bearophileHUGS lycos.com> writes:

Aligned memory for array ops:

The MMX (etc), SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSE5, AVE
instructions require data aligned to 8/16 bytes (and maybe more in the future,
the D language has to be flexible for things present in the CPUs 3 years from
now), the current array ops of D contain code that manages such problems in the
alignment, but I presume properly aligned data may lead to better performance.

If the static/dynamic pointers in D aren't guaranteed to be aligned to 8/16
(and in the future maybe 32 bytes) then a syntax may be added to ensure it. 

I presume that something like this may solve the problem with dynamically
allocated pointers, but it's not nice looking, it's error-prone, and you have
to keep both pointers around in your program:

memPtr = malloc(sizeInBytes + alignmentInBytes - 1);
alignedPtr = (T*)( ((int)memPtr + alignmentInBytes - 1) & ~(alignmentInBytes -
1) );

A first possible syntax (mostly by LeoD):

align(16) int[10] a; // static
auto a = align(32) new int[100]; // dynamic pointer

Bye,
bearophile

Pete <example example.com> writes:

bearophile Wrote:

 Aligned memory for array ops:
 
 The MMX (etc), SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSE5, AVE
instructions require data aligned to 8/16 bytes (and maybe more in the future,
the D language has to be flexible for things present in the CPUs 3 years from
now), the current array ops of D contain code that manages such problems in the
alignment, but I presume properly aligned data may lead to better performance.
 
 If the static/dynamic pointers in D aren't guaranteed to be aligned to 8/16
(and in the future maybe 32 bytes) then a syntax may be added to ensure it. 
 
 I presume that something like this may solve the problem with dynamically
allocated pointers, but it's not nice looking, it's error-prone, and you have
to keep both pointers around in your program:
 
 memPtr = malloc(sizeInBytes + alignmentInBytes - 1);
 alignedPtr = (T*)( ((int)memPtr + alignmentInBytes - 1) & ~(alignmentInBytes -
1) );
 
 A first possible syntax (mostly by LeoD):
 
 align(16) int[10] a; // static
 auto a = align(32) new int[100]; // dynamic pointer
 
 Bye,
 bearophile

Ah. You got there before me :-)

Don <nospam nospam.com.au> writes:

bearophile wrote:
 Aligned memory for array ops:
 
 The MMX (etc), SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSE5, AVE
instructions require data aligned to 8/16 bytes (and maybe more in the future,
the D language has to be flexible for things present in the CPUs 3 years from
now), the current array ops of D contain code that manages such problems in the
alignment, but I presume properly aligned data may lead to better performance.
 
 If the static/dynamic pointers in D aren't guaranteed to be aligned to 8/16
(and in the future maybe 32 bytes) then a syntax may be added to ensure it. 

Dynamic and static memory allocation of arrays is guaranteed to be 
aligned to 16 since D1.023.
Stack-allocated arrays aren't yet aligned. I've added a possible 

There'll always be a problem with slicing, though -- if you start a 
slice from an odd index, it's going to be misaligned.

Wayne Anderson <wanderon comcast.net> writes:

Don Wrote:

 bearophile wrote:
 Aligned memory for array ops:
 
 The MMX (etc), SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, SSE4a, SSE5, AVE
instructions require data aligned to 8/16 bytes (and maybe more in the future,
the D language has to be flexible for things present in the CPUs 3 years from
now), the current array ops of D contain code that manages such problems in the
alignment, but I presume properly aligned data may lead to better performance.
 
 If the static/dynamic pointers in D aren't guaranteed to be aligned to 8/16
(and in the future maybe 32 bytes) then a syntax may be added to ensure it. 

 
 Dynamic and static memory allocation of arrays is guaranteed to be 
 aligned to 16 since D1.023.
 Stack-allocated arrays aren't yet aligned. I've added a possible 

 There'll always be a problem with slicing, though -- if you start a 
 slice from an odd index, it's going to be misaligned.
 
 
 

I don't understand that.  Doesn't it depend on the size of the data type being
stored in the array.  If the size of the type being stored is a multiple of 16
shouldn't any slice still be aligned?

"Koroskin Denis" <2korden gmail.com> writes:

On Mon, 11 Aug 2008 22:13:03 +0400, Wayne Anderson <wanderon comcast.net>  
wrote:

 Don Wrote:

 bearophile wrote:
 Aligned memory for array ops:

 The MMX (etc), SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, SSE4a,  

 SSE5, AVE instructions require data aligned to 8/16 bytes (and maybe  
 more in the future, the D language has to be flexible for things  
 present in the CPUs 3 years from now), the current array ops of D  
 contain code that manages such problems in the alignment, but I presume  
 properly aligned data may lead to better performance.
 If the static/dynamic pointers in D aren't guaranteed to be aligned  

 to 8/16 (and in the future maybe 32 bytes) then a syntax may be added  
 to ensure it.

 Dynamic and static memory allocation of arrays is guaranteed to be
 aligned to 16 since D1.023.
 Stack-allocated arrays aren't yet aligned. I've added a possible

 There'll always be a problem with slicing, though -- if you start a
 slice from an odd index, it's going to be misaligned.

 I don't understand that.  Doesn't it depend on the size of the data type  
 being stored in the array.  If the size of the type being stored is a  
 multiple of 16 shouldn't any slice still be aligned?


with those types.