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