www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Alignment of dynamic arrays

reply "Luc Bourhis" <ljbo nowhere.com> writes:
With "auto a = new double[1000]", is there any guarantee that  
a.ptr is aligned on a 16-byte boundary? Indeed I would like to 
use core.simd and this alignment is paramount for efficient 
loading from memory to SSE2 registers.

On MacOS X and 64-bit Linux, it looks true for dmd. Looking at 
the implementation of arrays, it seems that it eventually depends 
on gc_malloc implementation but I could not find the code of that 
extern(C) function.
Jan 08 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Luc Bourhis:


 With "auto a = new double[1000]", is there any guarantee that  
 a.ptr is aligned on a 16-byte boundary?


Arrays are aligned on a 16-byte. But if you slice them, this 
alignment can be broken.

In past I suggested to put the alignment of an array in the D 
type system, as an optional extra information (if the alignment 
is not correct this causes compile-time errors in some cases and 
some run-time errors when the slicing bounds are runtime values).

Bye,
bearophile
Jan 08 2015
next sibling parent "Luc Bourhis" <ljbo nowhere.com> writes:
On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote:

 Luc Bourhis:


 With "auto a = new double[1000]", is there any guarantee that  
 a.ptr is aligned on a 16-byte boundary?


 Arrays are aligned on a 16-byte.


Good news!


 But if you slice them, this alignment can be broken.


Yes, of course. It's part of the game to prevent 
alignment-breaking slices.


 In past I suggested to put the alignment of an array in the D 
 type system, as an optional extra information (if the alignment 
 is not correct this causes compile-time errors in some cases 
 and some run-time errors when the slicing bounds are runtime 
 values).


I like the general idea. But it would seem more natural to me if 
a slice returned an aligned array if possible, otherwise a 
misaligned one.

Thanks for your thorough answer!
Jan 08 2015
prev sibling parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote:

 Luc Bourhis:


 With "auto a = new double[1000]", is there any guarantee that  
 a.ptr is aligned on a 16-byte boundary?


 Arrays are aligned on a 16-byte. But if you slice them, this 
 alignment can be broken.


IMO, If you slice a double array it is always aligned. Because 
doubles are 8 bytes long aka 64bit which would align them to 
every fourth 16bit boundary.
Jan 09 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/9/15 6:08 AM, Robert burner Schadek wrote:

 On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote:

 Luc Bourhis:


 With "auto a = new double[1000]", is there any guarantee that a.ptr
 is aligned on a 16-byte boundary?


 Arrays are aligned on a 16-byte. But if you slice them, this alignment
 can be broken.


 IMO, If you slice a double array it is always aligned. Because doubles
 are 8 bytes long aka 64bit which would align them to every fourth 16bit
 boundary.


not 16 bit, 16 byte.

-Steve
Jan 09 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 9 January 2015 at 11:18:18 UTC, Steven Schveighoffer 
wrote:

 not 16 bit, 16 byte.


SIMD on Intel Mic is 64 bytes, AVX2 is probably 32 bytes.
Jan 09 2015
prev sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
 not 16 bit, 16 byte.

 -Steve


known how to read helps, of course you're right.
Jan 09 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Robert burner Schadek:


 IMO, If you slice a double array it is always aligned. Because 
 doubles are 8 bytes long aka 64bit which would align them to 
 every fourth 16bit boundary.


If you have a 16-byte aligned array of doubles and you slice the 
first double away, what's the alignment of the result?

Bye,
bearophile
Jan 09 2015
parent reply "Robert burner Schadek" <rburners gmail.com> writes:
On Friday, 9 January 2015 at 11:19:47 UTC, bearophile wrote:

 If you have a 16-byte aligned array of doubles and you slice 
 the first double away, what's the alignment of the result?


the first double[0] is 16-byte aligned, double[1] would be 
20-byte aligned as a double is 4 byte long.

p.s. I'm properly wrong as my last two posts contained errors
Jan 09 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/9/15 7:43 AM, Robert burner Schadek wrote:

 On Friday, 9 January 2015 at 11:19:47 UTC, bearophile wrote:

 If you have a 16-byte aligned array of doubles and you slice the first
 double away, what's the alignment of the result?


 the first double[0] is 16-byte aligned, double[1] would be 20-byte
 aligned as a double is 4 byte long.

 p.s. I'm properly wrong as my last two posts contained errors


*sigh* s/20/24, s/4 byte/8 byte :)

-Steve
Jan 09 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/9/15 8:02 AM, Steven Schveighoffer wrote:

 On 1/9/15 7:43 AM, Robert burner Schadek wrote:

 On Friday, 9 January 2015 at 11:19:47 UTC, bearophile wrote:

 If you have a 16-byte aligned array of doubles and you slice the first
 double away, what's the alignment of the result?


 the first double[0] is 16-byte aligned, double[1] would be 20-byte
 aligned as a double is 4 byte long.

 p.s. I'm properly wrong as my last two posts contained errors


 *sigh* s/20/24, s/4 byte/8 byte :)


Bleh, even that is wrong :) second element would be 8-byte aligned, not 
24-byte aligned.

-Steve
Jan 09 2015
parent "Luc Bourhis" <ljbo nowhere.com> writes:
Keeping alignment when slicing is easy since it matches the size 
of the xmm registers: one has to partition the array by blocks of 
2 doubles, 4 floats, etc. For AVX, the ideal alignment is on 
32-byte boundaries but the really bad performance hit happens 
only when an unaligned access crosses a cacheline boundary. With 
SSE2, this concerns every single access.
Jan 09 2015