www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - __vector(ubyte[32]) misalignment

reply Bruce Carneal <bcarneal gmail.com> writes:
The .alignof attribute of __vector(ubyte[32]) is 32 but 
initializing an array of such vectors via an assignment to 
.length has given me 16 byte alignment (and subsequent seg faults 
which I suspect are related).

Is sub .alignof alignment expected here?  IOW, do I have to 
manually manage memory if I want alignments above 16?
Aug 08 2020
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 The .alignof attribute of __vector(ubyte[32]) is 32 but 
 initializing an array of such vectors via an assignment to 
 .length has given me 16 byte alignment (and subsequent seg 
 faults which I suspect are related).

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


Manually managing the alignment eliminated the seg faulting.

Additionally, I found that std.experimental.mallocator 
Mallocator.alignment is 16.

So, is the misalignment baked in at this point?
Aug 08 2020
parent reply user1234 <user123 12.de> writes:
On Sunday, 9 August 2020 at 01:56:54 UTC, Bruce Carneal wrote:

 On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 The .alignof attribute of __vector(ubyte[32]) is 32 but 
 initializing an array of such vectors via an assignment to 
 .length has given me 16 byte alignment (and subsequent seg 
 faults which I suspect are related).

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


 Manually managing the alignment eliminated the seg faulting.

 Additionally, I found that std.experimental.mallocator 
 Mallocator.alignment is 16.

 So, is the misalignment baked in at this point?


there's AlignedMallocator that allows to overrides the 
"platformAlignment".
To get vector spece Mallocator is indeed a bad choice.
Aug 08 2020
parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 9 August 2020 at 05:49:23 UTC, user1234 wrote:

 On Sunday, 9 August 2020 at 01:56:54 UTC, Bruce Carneal wrote:

 On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 


 Manually managing the alignment eliminated the seg faulting.

 Additionally, I found that std.experimental.mallocator 
 Mallocator.alignment is 16.

 So, is the misalignment baked in at this point?


 there's AlignedMallocator that allows to overrides the 
 "platformAlignment".
 To get vector spece Mallocator is indeed a bad choice.


Yep.
Aug 09 2020
prev sibling next sibling parent reply Johan <j j.nl> writes:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 The .alignof attribute of __vector(ubyte[32]) is 32 but 
 initializing an array of such vectors via an assignment to 
 .length has given me 16 byte alignment (and subsequent seg 
 faults which I suspect are related).

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


Do you have a code example?
And what compiler are you using?

-Johan
Aug 09 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 9 August 2020 at 09:58:18 UTC, Johan wrote:

 On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 The .alignof attribute of __vector(ubyte[32]) is 32 but 
 initializing an array of such vectors via an assignment to 
 .length has given me 16 byte alignment (and subsequent seg 
 faults which I suspect are related).

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


 Do you have a code example?
 And what compiler are you using?

 -Johan


At run.dlang.io recent runs of both dmd and lcd compilations of 
the below revealed misalignment.

import std;

void main()  safe
{
     alias V = __vector(ubyte[32]); // requires -mcpu=native or 
other on cmd line
     V[] va;
     size_t misalignments;
     foreach(N; 1..101) {
     	va.length = N;
     	const uptr = cast(ulong)va.ptr;
         misalignments += (uptr % V.alignof) != 0;
     }
     writefln("misaligned %s per cent of the time", misalignments);
}
Aug 09 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/9/20 8:09 AM, Bruce Carneal wrote:

 On Sunday, 9 August 2020 at 09:58:18 UTC, Johan wrote:

 On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 The .alignof attribute of __vector(ubyte[32]) is 32 but initializing 
 an array of such vectors via an assignment to .length has given me 16 
 byte alignment (and subsequent seg faults which I suspect are related).

 Is sub .alignof alignment expected here?  IOW, do I have to manually 
 manage memory if I want alignments above 16?


 Do you have a code example?
 And what compiler are you using?

 -Johan


 
 At run.dlang.io recent runs of both dmd and lcd compilations of the 
 below revealed misalignment.
 
 import std;
 
 void main()  safe
 {
      alias V = __vector(ubyte[32]); // requires -mcpu=native or other on 
 cmd line
      V[] va;
      size_t misalignments;
      foreach(N; 1..101) {
          va.length = N;
          const uptr = cast(ulong)va.ptr;
          misalignments += (uptr % V.alignof) != 0;
      }
      writefln("misaligned %s per cent of the time", misalignments);
 }


All blocks in the GC that are more than 16 bytes are aligned by 32 
bytes. You shouldn't have any 16 byte blocks here, because each element 
is 32 bytes long.

However, if your block grows to a page size, the alignment will be 16 
bytes off (due to the metadata stored at the front of the block).

A page size is 4096 bytes. So anything larger than 2048 will require a 
page-sized block or larger.

I would guess that once your array gets longer than.... 63 elements, 
it's always misaligned?

The current code ensures a 16 byte alignment. That really should go to 
32 (for this reason). I think this has come up before, there may even be 
a bug report on it.

See: 
https://github.com/dlang/druntime/blob/660d911bbd3342c1f1c1478d12e3e943c6038da0/src/rt/lifetime.d#L35

The other thing you can do is avoid allocating using the array runtime, 
and just allocate using the GC calls directly. This means appending 
won't work, and neither will destructors (though that shouldn't be 
important here).

Question for those in the know: are there any other alignments that we 
should ensure are possible?

-Steve
Aug 09 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/9/20 8:37 AM, Steven Schveighoffer wrote:


 I think this has come up before, there may even be 
 a bug report on it.


Found one, I'll see if I can fix the array runtime:

https://issues.dlang.org/show_bug.cgi?id=10826

-Steve
Aug 09 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/9/20 8:46 AM, Steven Schveighoffer wrote:

 On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
 

 I think this has come up before, there may even be a bug report on it.


 
 Found one, I'll see if I can fix the array runtime:
 
 https://issues.dlang.org/show_bug.cgi?id=10826
 


Bruce, I have a PR to hopefully fix these issues, if you want to test 
against it:

https://github.com/dlang/druntime/pull/3192

-Steve
Aug 10 2020
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 10 August 2020 at 13:52:46 UTC, Steven Schveighoffer 
wrote:

 On 8/9/20 8:46 AM, Steven Schveighoffer wrote:

 On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
 

 I think this has come up before, there may even be a bug 
 report on it.


 
 Found one, I'll see if I can fix the array runtime:
 
 https://issues.dlang.org/show_bug.cgi?id=10826
 


 Bruce, I have a PR to hopefully fix these issues, if you want 
 to test against it:

 https://github.com/dlang/druntime/pull/3192

 -Steve


The "fix issue 10826" reading was interesting.  Thanks for 
pushing this one through.
Aug 10 2020
prev sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 10 August 2020 at 13:52:46 UTC, Steven Schveighoffer 
wrote:

 On 8/9/20 8:46 AM, Steven Schveighoffer wrote:

 On 8/9/20 8:37 AM, Steven Schveighoffer wrote:
 

 I think this has come up before, there may even be a bug 
 report on it.


 
 Found one, I'll see if I can fix the array runtime:
 
 https://issues.dlang.org/show_bug.cgi?id=10826
 


 Bruce, I have a PR to hopefully fix these issues, if you want 
 to test against it:

 https://github.com/dlang/druntime/pull/3192

 -Steve


No biggee but it looks like there is some duplicate code at the 
end of the __alignPad unittest.
Aug 10 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/10/20 2:53 PM, Bruce Carneal wrote:


 No biggee but it looks like there is some duplicate code at the end of 
 the __alignPad unittest.


Hah! I think I copy-pasted that intending to write a new test, but then 
tried it separately and found another issue 
(typeid(__vector(ubyte[32])).talign returned 16!)

So I forgot to go back in and delete that case.

Thanks

-Steve
Aug 10 2020
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 9 August 2020 at 12:37:06 UTC, Steven Schveighoffer 
wrote:

 On 8/9/20 8:09 AM, Bruce Carneal wrote:

 [...]


 All blocks in the GC that are more than 16 bytes are aligned by 
 32 bytes. You shouldn't have any 16 byte blocks here, because 
 each element is 32 bytes long.

 However, if your block grows to a page size, the alignment will 
 be 16 bytes off (due to the metadata stored at the front of the 
 block).

 A page size is 4096 bytes. So anything larger than 2048 will 
 require a page-sized block or larger.

 I would guess that once your array gets longer than.... 63 
 elements, it's always misaligned?


Quality sleuthing Steve. The program says it found misalignments 
with 37 out of 100 attempts of length [1..100].
Aug 09 2020
prev sibling parent reply kinke <noone nowhere.com> writes:
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


IIRC, yes when using the GC, as that only guarantees 16-bytes 
alignment. Static arrays on the stack should be aligned just fine 
with LDC.
Aug 09 2020
parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 9 August 2020 at 10:02:32 UTC, kinke wrote:

 On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote:

 Is sub .alignof alignment expected here?  IOW, do I have to 
 manually manage memory if I want alignments above 16?


 IIRC, yes when using the GC, as that only guarantees 16-bytes 
 alignment. Static arrays on the stack should be aligned just 
 fine with LDC.


Yes, it presents as a GC limitation.

Many thanks for your LDC work.
Aug 09 2020