<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 8:47 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></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"><br>
> On 2014 Oct 16, at 22:09, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
> Dig into this first!<br>
<br>
This isn't the right forum for digging into ld64.<br>
<span class=""><br>
> In the OP you are talking about essentially a pure "optimization" (in the programmer-wisdom "beware of it" sense), to "save" 2GB of peak memory. But from your analysis it's not clear that this 2GB savings actually is reflected as peak memory usage saving<br>
<br>
</span>It's reflected in both links.<br></blockquote><div><br></div><div>Then it follows that there is ~15GB of low-hanging fruit that can be trivially shaved off by just splitting the last part of LTO into an independent call into llvm-lto. Although identifying the root cause would be better; as Alex said we don't want to make the same mistake in LLD.</div><div><br></div><div>It doesn't make sense to follow an "aggressive plan" for 2GB savings when there is 15GB of low-hanging fruit. 2GB is *at most* 12% of the total we can *ever* expect to shave off (12% = 2/(15+2) <= 2/(15 + 2 + any other saving); this 15GB is *at least* 50% of the the memory we can ever expect to shave off (50% = 15/30 >= 15/(30 - anything we can't eliminate)).</div><div> </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">
<span class=""><br>
> (since the ~30GB peak might be happening elsewhere in the LTO process). It is this ~30GB peak, and not the one you originally analyzed, which your customers presumably care about.<br>
<br>
</span>This discussion is intentionally focused on llvm-lto.<br></blockquote><div><br></div><div>What is the intention? Do your customers actually run llvm-lto? I and at least one of my officemates didn't even know it existed.</div><div> </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">
<span class=""><br>
> To recap, the analysis you performed seems to support neither of the following conclusions:<br>
> - Peak memory usage during LTO would be improved by this plan<br>
<br>
</span>The analysis is based on the nodes allocated at peak memory.<br>
<span class=""><br>
> - Build time for LTO would be improved by this plan (from what you have posted, you didn't measure time at all)<br>
<br>
</span>CPU profiles blame 25-35% of the CPU of the ld64 LTO link on<br>
callback-based metadata RAUW traffic, depending on the C++ program.<br></blockquote><div><br></div><div>Wow, that's a lot. How much of this do you think your plan will be able to shave off?</div><div>Did you see anything else on the profile? A pie chart would be much appreciated.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>Sorry if I sound "grouchy", but this seems like the classic situation where the someone comes to you asking for X, but what they really want is a solution to underlying problem Y, for which the best solution, once you actually analyze Y, is Z. Here X is debug info size, Y is excessive LTO time or excessive LTO memory usage, and Z is yet to be determined. It sounds to me like you started with an a priori idea of changing debug info and then tried to justify it a posteriori. A "solution looking for a problem". And since the focus has been on debug info, the results haven't been put in context: 2GB savings can be small or big; it's negligible compared to the 15GB flying under the radar.</div><div><br></div><div>Is there a particular reason you are so intent on changing the debug info? It may very well be that a change to debug info will be the right solution. But your analyses don't seem to be aimed at establishing what is the right solution (nor does it seem like anybody has done such analyses); your analyses seem to be aimed at generating numbers for debug info, and as a result insufficient attention has been paid to putting the numbers in proper context so that it is clear what their significance is.</div><div><br></div><div>To summarize the discussion so far, it seems that the plan ranks on the following dimensions:</div><div>compatibility - looks interesting</div><div>maintainability - unclear</div><div>peak memory usage - ~6% improvement (2GB of 30GB)</div><div>build time - promising, maybe up to ~30%</div><div><br></div><div>-- Sean Silva</div><div> </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">
<span class=""><br>
> Of course, this is all tangential to the discussion of e.g. a more readable/writable .ll form for debug info, or debug info compatibility. However, it seems like you jumped into this from the point of view of it being an optimization, rather than a maintainability/compatibility thing.<br>
<br>
</span>It's both.</blockquote></div><br></div></div>