Hi Chandler, <div><br /></div><div><blockquote cite="mid:CAGCO0Kj=UKfZkd5Fx5f5D0j5P=cwkNtnmBgRXrFQ9fNNyoUg=w@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FWIW, I don't yet agree.</div><div><br /></div><div>Your tables show many programs growing in code size by over 20%. While there is associated performance improvements, it isn't clear that this is a good tradeoff. Historically, optimizations which optimize as a direct result of growing code size have *not* been an acceptable tradeoff in -Os.</div></div></div></div></div></blockquote><div><br /></div><div>I am glad that you mentioned it. There are only three benchmarks that gained over 1% and there is only one benchmark that gained over 20%: the TSVC workloads.   The TSVC is an HPC benchmark and it is irrelevant for the -Os/-O2 discussion.  If you ignore TSVC you will notice that the code growth due to vectorization is 0.01%  </div><blockquote cite="mid:CAGCO0Kj=UKfZkd5Fx5f5D0j5P=cwkNtnmBgRXrFQ9fNNyoUg=w@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br /></div><div>From Owen's email, a characterization I agree with:</div><div>"<span style="font-size:13px;font-family:arial,sans-serif">My understanding is that -Os is intended to be optimized-without-sacrificing-</span><span style="font-size:13px;font-family:arial,sans-serif">code-size."</span></div>
<div><br /></div><div><font face="arial, sans-serif">The way I would phrase the difference between -Os and -Oz is similar: with -Os we don't *grow* the code size significantly even if it gives significant performance gains, whereas with -Oz we *shrink* the code size even if it means significant performance loss.</font></div>
<div><font face="arial, sans-serif"><br /></font></div><div><font face="arial, sans-serif">Neither of these concepts for -Os would seem to argue for running the vectorizer given the numbers you posted.</font></div></div></div></div></div></blockquote><div><br /></div><div>0.01% code growth for everything except TSVC sounds pretty good to me.  I would be willing to accept 0.01% code growth to gain 2% on gzip and 9% on RC4. </div><div ><br/></div><blockquote cite="mid:CAGCO0Kj=UKfZkd5Fx5f5D0j5P=cwkNtnmBgRXrFQ9fNNyoUg=w@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><font face="arial, sans-serif"></font></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"><div style="word-wrap:break-word"><div> Regarding -O2 vs -O3, maybe we should set a higher cost threshold for O2 to increase the likelihood of improving the performance ?  We have very few regressions on -O3 as is and with better cost models I believe that we can bring them close to zero, so I am not sure if it can help that much.   Renato, I prefer not to estimate the encoding size of instructions. We know that vector instructions take more space to encode. Will knowing the exact number help us in making a better decision ? I don’t think so. On modern processors when running vectorizable loops, the code size of the vector instructions is almost never the bottleneck.</div>
</div></blockquote><div><br /></div><div>That has specifically not been my experience when dealing with significantly larger and more complex application benchmarks.</div><div ><br/></div></div></div></div></div></blockquote><div>I am constantly benchmarking the compiler and I am aware of a small number of regressions on -O3 using the vectorizer.   If you have a different experience then please share your numbers.   </div><div><br /></div><blockquote cite="mid:CAGCO0Kj=UKfZkd5Fx5f5D0j5P=cwkNtnmBgRXrFQ9fNNyoUg=w@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br /></div><div>The tradeoffs you show in your numbers for -Os are actually exactly what I would expect for -O2: a willingness to grow code size (and compilation time) in order to get performance improvements. A quick eye-balling of the two tables seemed to show most of the size growth had associated performance growth. This, to me, is a good early indicator that the mode of the vectorizer is running in your -Os numbers is what we should look at enabling for -O2.</div>
<div><br /></div><div>That said, I would like to see benchmarks from a more diverse set of applications than the nightly test suite. ;] I don't have a lot of faith in it being representative. I'm willing to contribute some that I care about (given enough time to collect the data), but I'd really like for other folks with larger codebases and applications to measure code size and performance artifacts as well.</div></div></div></div></div></blockquote><div><br /></div><div>I am looking forward to seeing your contributions to the nightly test suite.  I would also like to see other people benchmark their applications. </div><div><br /></div><div>Thanks,</div><div>Nadav</div><blockquote cite="mid:CAGCO0Kj=UKfZkd5Fx5f5D0j5P=cwkNtnmBgRXrFQ9fNNyoUg=w@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimepart text html"><div dir="ltr"><div class="gmail_extra"><div><br/></div></div></div>
</div></blockquote></div>