Re: __vector(ubyte[32]) misalignment
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
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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
Re: __vector(ubyte[32]) misalignment
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].
Re: __vector(ubyte[32]) misalignment
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
Re: __vector(ubyte[32]) misalignment
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
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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);
}
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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
Re: __vector(ubyte[32]) misalignment
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.
Re: __vector(ubyte[32]) misalignment
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?
__vector(ubyte[32]) misalignment
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?
