Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
not 16 bit, 16 byte. -Steve known how to read helps, of course you're right.
Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
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.
Re: Alignment of dynamic arrays
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.
Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
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.
Re: Alignment of dynamic arrays
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
Re: Alignment of dynamic arrays
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!
