<div dir="ltr">On 21 June 2013 00:03, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Manu:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They must be aligned, and multiples of N elements.<br>
</blockquote>
<br></div>
The D GC currently allocates them 16-bytes aligned (but if you slice the array you can lose some alignment). On some new CPUs the penalty for misalignment is small.<br></blockquote><div><br></div><div style>Yes, the GC allocates 16byte aligned memory, this is good. It's critical actually. But if the data types themselves weren't aligned, then the alloc alignment would be lost as soon as they were used in struct's.</div>
<div style><br></div><div style>You'll notice I made a point of focusing on _portable_ simd. It's true, some new chips can deal with it at virtually no additional cost, but they lose nothing by aligning their data regardless, and you can run on anything.<br>
</div><div style>I hope that people write libraries that can run well on anything, not just their architecture of choice. The guidelines I presented, if followed, will give you good performance on all architectures.</div>
<div style>They're not even very inconvenient.</div><div style><br></div><div style>If your point is about auto-vectorisation being much simpler without the alignment restrictions, this is true. But again, I'm talking about portable and RELIABLE implementations, that is, the programmer should know that SIMD was used effectively, and not have to hope the optimiser was able to do a good job. Make these guidelines second nature, and you'll foster a habit of writing portable code even if you don't intend to do so personally. Someone somewhere may want to use your library...</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You often have "n" values, where n is variable. If n is large enough and you are using D vector ops, the handling of the head and tail doesn't waste too much time. If you have very few values it's much better to use the SIMD code.</blockquote>
<div><br></div><div style>See my later slides about branch predictability. When you need to handle stragglers on the head or tail, then you've introduced 2 sources of unpredictability (and also bloated your code).</div>
<div style>If the arrays are very long, this may be okay as you say, but if they're not it becomes significant.</div><div style><br></div><div style>But there is an new issue that appears; if the output array is not the same as the input array, then you have a new mis-alignment where the bases of the 2 arrays might not share the same alignment, and you can't do a simd load from one and store to the other without a series of corrective shifts and merges, which will effectively result in similar code to my un-aligned load demonstration.</div>
<div style><br></div><div style>So the case where this is reliable is:</div><div style> * long data array</div><div style> * output array is the same as the input array (overwrites the input?)</div><div style><br></div><div style>
I don't consider that reliable, and I don't think special-cases awareness of those criteria is any easier than carefully/deliberately using SIMD in the first place.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, each are valid comparisons in different situations. I'm not sure how syntax could clearly select the one you want.<br>
</blockquote>
<br></div>
Maybe later we'll look for some syntax sugar for this.<br></blockquote><div><br></div><div style>I'm definitely curious... but i'm not sure it's necessary.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Are D intrinsics offering instructions to perform prefetching?<br>
</blockquote>
<br></div><div class="im">
Well, GCC does at least. If you're worried about performance at this level, you're probably already using GCC :)<br>
</div></blockquote>
<br>
I think D SIMD programmers will expect something functionally like __builtin_prefetch to be available in D too:<br>
<a href="http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-g_t_005f_005fbuiltin_005fprefetch-3396" target="_blank">http://gcc.gnu.org/onlinedocs/<u></u>gcc/Other-Builtins.html#index-<u></u>g_t_005f_005fbuiltin_<u></u>005fprefetch-3396</a></blockquote>
<div><br></div><div style>Yup, I toyed with the idea of adding it to std.simd, but I didn't think it fit there.</div></div></div></div>