<div dir="ltr">Thank you. I&#39;ve filed:<div><a href="https://bugs.swift.org/browse/SR-203">https://bugs.swift.org/browse/SR-203</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 7:04 PM, Mark Lacey <span dir="ltr">&lt;<a href="mailto:mark.lacey@apple.com" target="_blank">mark.lacey@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Dec 11, 2015, at 6:05 AM, Jens Persson via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Correction: The test I&#39;m running is actually using V4&lt;V4&lt;Float&gt;&gt;.<div>Manually unrolling the loop makes adding V4&lt;V4&lt;Float&gt;&gt; as fast as adding SIMD float4x4.</div><div>Using the (un-unrolled) for loop will be about 4 times slower.</div><div>My question is still: Shouldn&#39;t the optimizer be able to handle that for loop / make my manual unrolling unnecessary?</div><div>/Jens</div></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 8:28 AM, Jens Persson<span> </span><span dir="ltr">&lt;<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>&gt;</span><span> </span>wrote:<br><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"><div dir="ltr"><div><div>I&#39;ve been doing a lot of performance testing related to generic value types and SIMD lately, and I&#39;ve built Swift from sources in order to get an idea of what&#39;s coming up optimizerwise. Things have improved and the optimizer is impressive overall. But I still see no improvement in the case exemplified below.</div><div><br></div><div>Manually unrolling the simple for loop will make it ~ 4 times faster (and exactly the same as when SIMD float4):<br></div><div><br></div><div>struct V4&lt;T&gt; {</div><div>   <span> </span>var elements: (T, T, T, T)</div><div>   <span> </span>/.../</div><div>   <span> </span>subscript(index: Int) -&gt; T { /.../ }</div><div>   <span> </span>/.../</div><div>   <span> </span>func addedTo(other: V4) -&gt; V4 {</div><div>       <span> </span>var r = V4()</div><div>       <span> </span>// Manually unrolling makes code ~ 4 times faster:</div><div>       <span> </span>// for i in 0 ..&lt; 4 { r[i] = self[i] + other[i] }</div><div>       <span> </span>r[0] = self[0] + other[0]</div><div>       <span> </span>r[1] = self[1] + other[1]</div><div>       <span> </span>r[2] = self[2] + other[2]</div><div>       <span> </span>r[3] = self[3] + other[3]</div><div>       <span> </span>return r</div><div>   <span> </span>}</div><div>   <span> </span>/.../</div><div>}</div><div><br></div><div>Shouldn&#39;t the optimizer be able to handle that for loop and make the manual unrolling unnecessary?</div></div></div></blockquote></div></div></div></blockquote><div><br></div></div></div>In theory, yes. In practice there are some fairly complex phase ordering issues in the SIL optimizer, and certain optimizations (like general loop unrolling) that are only done in the LLVM optimizer. The LLVM optimizer runs after all the SIL-level optimizations, which may mean that SIL-level optimization opportunities are exposed by the LLVM optimizer but by then it is too late to do anything about them.</div><div><br></div><div><span class=""><blockquote type="cite"><div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><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"><div dir="ltr"><div><div>(compiled the test with -O -whole-module-optimizations, also tried -Ounchecked but with same results.)</div></div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>Would you mind opening an issue on <a href="https://bugs.swift.org" target="_blank">https://bugs.swift.org</a> will a small stand-alone test case that compiles successfully, and report your results there?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Mark</div></font></span></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>