On 9 October 2012 20:46, jerro <span dir="ltr"><<a href="mailto:a@a.com" target="_blank">a@a.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tuesday, 9 October 2012 at 16:59:58 UTC, Jacob Carlborg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-10-09 16:52, Simen Kjaeraas wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nope, like:<br>
<br>
module std.simd;<br>
<br>
version(Linux64) {<br>
    public import std.internal.simd_linux64;<br>
}<br>
<br>
<br>
Then all std.internal.simd_* modules have the same public interface, and<br>
only the version that fits /your/ platform will be included.<br>
</blockquote>
<br>
Exactly, what he said.<br>
</blockquote>
<br></div></div>
I'm guessing the platform in this case would be the CPU architecture, since that determines what SIMD instructions are available, not the OS. But anyway, this does not address the problem Manu was talking about. The problem is that the API for the intrisics for the same architecture is not consistent across compilers. So for example, if you wanted to generate the instruction "movaps XMM1, XMM2, 0x88" (this extracts all even elements from two vectors), you would need to write:<br>

<br>
version(GNU)<br>
{<br>
    return __builtin_ia32_shufps(a, b, 0x88);<br>
}<br>
else version(LDC)<br>
{<br>
    return shufflevector(a, b, 0, 2, 4, 6);<br>
}<br>
else version(DMD)<br>
{<br>
    // can't do that in DMD yet, but the way to do it will probably be different from the way it is done in LDC and GDC<br>
}<br>
<br>
What Manu meant with having std.simd.sse and std.simd.neon was to have modules that would provide access to the platform dependent instructions that would be portable across compilers. So for the shufps instruction above you would have something like this ins std.simd.sse:<br>

<br>
float4 shufps(int i0, int i1, int i2, int i3)(float4 a, float4 b){ ... }<br>
<br>
std.simd currently takes care of cases when the code can be written in a cross platform way. But when you need to use platform specific instructions directly, std.simd doesn't currently help you, while std.simd.sse, std.simd.neon and others would. What Manu is worried about is that having instructions wrapped in another level of functions would hurt performance. It certainly would slow things down in debug builds (and IIRC he has written in his previous posts that he does care about that). I don't think it would make much of a difference when compiled with optimizations turned on, at least not with LDC and GDC.<br>

</blockquote></div><br><div>Perfect! You saved me writing anything at all ;)</div><div><br></div><div>I do indeed care about debug builds, but one interesting possibility that I discussed with Walter last week was a #pragma inline statement, which may force-enable inlining even in debug. I'm not sure how that would translate to GDC/LDC, and that's an important consideration. I'd also like to prove that the code-gen does work well with 2 or 3 levels of inlining, and that the optimiser is still able to perform sensible code reordering in the target context.</div>