<div dir="ltr">On 16 August 2013 04:39, bearophile <span dir="ltr"><<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The XMM registers I am using are efficient when you feed them memory from arrays aligned to 16 bytes, as the D GC produces. But the YMM registers used by the AVX/AVX2 instructions prefer an alignment of 32 bytes. And the Intel Xeon Phi (MIC) has XMM registers that are efficient when the arrays are aligned to 64 bytes.<br>

<br>
When I am not using SIMD code, and I want a small array of little elements, like an array of 10 ushorts, having it aligned to 16 bytes is a waste of space (despite helps the GC reduce the fragmentation).<br></blockquote>
<div><br></div><div>I'd argue that if you're alloc-ing many instances of 10 short's independently on the heap, then you're probably doing it wrong.</div><div>If you're only doing it once or twice, then it's not a significant waste of memory as you say.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So I have written a small enhancement request, where I suggest that arrays for YMM registers could be allocated with an alignment of 32 bytes:<br>
<a href="http://d.puremagic.com/issues/show_bug.cgi?id=10826" target="_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=10826</a></blockquote><div><br></div><div>This shouldn't be an enhancement request, it should be the rule. __vector()'s should be intrinsically aligned to their sizeof. If they are not, it should be a bug.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Having the array alignments in the D type system could be useful. To be backward-compatible you also need a generic unknown alignment (like a void* for alignments), so you can assign arrays of any alignment to it, it could be denoted with '0'.<br>

<br>
Some rough ideas:<br>
<br>
<br>
import core.simd: double2, double4;<br>
auto a = new int[10];<br>
static assert(__traits(alignment, a) == 16);<br>
auto b = new int[128]<32>;<br>
static assert(__traits(alignment, b) == 32);<br>
auto c1 = new double2[128];<br>
auto c2 = new double4[64];<br>
static assert(__traits(alignment, c1) == 16);<br>
static assert(__traits(alignment, c2) == 32);<br>
<br>
void foo1(int[]<32> a) {<br>
    // Uses YMM registers to modify a<br>
    // ...<br>
}<br>
<br>
void foo2(int[] a)<br>
if (__traits(alignment, a) == 32) {<br>
    // Uses YMM registers to modify a<br>
    // ...<br>
}<br>
<br>
void foo3(size_t N)(int[]<N> a) {<br>
    static if (N >= 32) {<br>
        // Uses YMM registers to modify a<br>
        // ...<br>
    } else {<br>
        // ...<br>
    }<br>
}<br></blockquote><div><br></div><div><div>The thing is, a/b/c1/c2 is really just: struct { size_t length; T *ptr; }</div><div>Those symbol names just refer to the dynamic array struct... It doesn't make a lot of sense to query the alignment of those symbols. __traits(alignment, s) would == sizeof(size_t) every time.</div>
</div><div><br></div><div>I've thought about this sort of thing many times before... but I'm not convinced. I still think it falls over with the possibility of slicing, and separate compilation.</div><div><br></div>
<div>The thing you're asking for is alignment of the base of the array, not alignment of elements within the array or alignment of the dynamic array structure its self.</div><div>Alignment of the base of the array isn't really expressible as part of the type. It's just a request to the allocator.</div>
<div>I use a mallocAligned() function in C. Sadly, I think this is one of the mistakes of a discreet 'new' operator, which has a syntax that doesn't lend its self to arbitrary parameters.</div></div></div></div>