<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 19, 2017 at 7:39 AM Greg Bedwell <<a href="mailto:gregbedwell@gmail.com">gregbedwell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I looked at a few more of my earlier results in more detail.  In particular, from one of our test suites that produces some interesting compile-time and memory usage data for clang on Windows hosts.</div><div><br></div><div>I did a comparison between "-O2 -g" and "-O2 -g -fexperimental-new-pass-manager".  As you'll see in the attached graphs, in general the suite contains some relatively small compilation units, mostly taking <5 seconds each to compile although there are a few larger ones in there too.  I'm using 64-bit clang.exe binary targeting the PS4 triple.  I've limited the test harness to run a single process at a time.</div><div>The first graph shows all of data points.  I'm plotting wall time along the X axis and PeakWorkingSetSize (see <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ms684877%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396" target="_blank">https://msdn.microsoft.com/en-us/library/windows/desktop/ms684877%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396</a> ) along the Y axis.  As you can see there are a few interesting outliers with the new pass manager on both axes.  I'd like to do more investigation here and possibly raise some bugs if I can make shareable reproducers.</div></div></blockquote><div><br></div><div>FWIW, the compile time regressions are a bit more interesting to me unless the memory regression is unusually problematic for you or someone else. See below...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><img src="cid:ii_15f3504c26449578" alt="extents.png" class="" style="max-width: 100%;"><br></div><div><br></div><div>The next graph is the same data, but I've zoomed right in on the bottom left corner to see that cluster with the greatest concentration of points in more detail:</div><div><img src="cid:ii_15f350a5ab05e3eb" alt="zoomed.png" class="" style="max-width: 100%;"><br></div><div><br></div><div>The clusters of data points generally map quite well to each other here.  There does seem to be a visible trend that the New PM is using more memory.  There's not enough data here to extrapolate any further (remember we're talking about <2 second compiles here), but it leaves me interested as to what the trend would be further out; in particular when applied to large LTO workloads where paging can become a big issue.  Essentially, is this a small, relatively constant overhead, or does it scale with overall memory usage?  I guess it's quite possible I'm seeing the effects of different inlining strategies.  This isn't necessarily a blocker either way, but it would be an interesting question to know the answer to.</div></div></blockquote><div><br></div><div>This is definitely something I'm expecting, but something I want us to watch closely.</div><div><br></div><div>The new PM caches analyses to avoid recomputing them. The good part of this is reduced recomputation of analyses. The bad part is using more memory. So the increase in memory *is* expected.</div><div><br></div><div>However, you might expect to see more reduction in compile time. Sadly, these reductions are a bit slow for a few bad reasons:</div><div><br></div><div>1) The code generator isn't using the new pass manager yet. =[ So it throws away cached results and recomputes them. This isn't any different from the old pass manager, but still frustrating because we spent peak memory on those results and didn't benefit from it.</div><div><br></div><div>2) A lot of the compile time goes to Clang and the code generator, hiding any improvements.</div><div><br></div><div>So, provided the memory increases are "OK" (IE, not causing significant resource starvation, or superlinear memory growth) I'm not too scared by them. I'm more interested in checking why there are compile time regressions.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>