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.

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

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!

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.

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

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

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.

>
> not 16 bit, 16 byte.
>
> -Steve

known how to read helps, of course you're right.

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

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