<div dir="auto"><div>Not really, as well as some sensitivity to the input data overall performance of the link with compression will depend on how this is implemented in lld - how is it parallelized? How is it chunked? Is it effectively pipelined with IO?<div dir="auto"><br></div><div dir="auto">Or, I wouldn't feel comfortable being able to make a recommendation to our end-users on whether to use this option or not based on my existing extensive benchmarking of zlib in isolation. It's necessary to test in real conditions. </div><div dir="auto"><br></div><div dir="auto">Thanks, </div><div dir="auto"><br></div><div dir="auto">Simon </div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 2 Aug 2018, 15:22 Rui Ueyama, <<a href="mailto:ruiu@google.com">ruiu@google.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 class="gmail_quote"><div dir="ltr">On Thu, Aug 2, 2018 at 2:05 PM Simon Whittaker <<a href="mailto:simon.f.whittaker@gmail.com" target="_blank" rel="noreferrer">simon.f.whittaker@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"><br><div>>
<span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">As to (3), in most cases, I believe it is rare to distribute executables with debug info widely</span>
</div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">>
<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>I think it is at least less important than (1).</span>
</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Agreed.</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">>
<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I think (1) is definitely the case, and that's also true for a distributed build system with which a lot of object files are copied between machines.</span>
</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> My suggestion was to use compression level 9 when both -O2 and -compress-debug-section=zlib are specified.</span>
<br></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Ok great, I'm less concerned if it still requires an explicit
<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">-compress-debug-section=zlib even with -O2 (I thought you were proposing to add to O2)</span></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Still for informational / advisory purposes it would be good for us to produce link time vs compression level vs total exe size, ideally with a couple of different storage types (at least PCIe SSD vs spinning) and CPUs.</span></span></span></div></div></blockquote><div><br></div><div>Debug sections are compresssed using zlib, so I think such benchmark would be testing the performance of zlib itself on various conditions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Thanks,</span></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Simon</span></span></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 2, 2018 at 1:17 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank" rel="noreferrer">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div>On Thu, Aug 2, 2018 at 10:24 AM Simon Whittaker via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br></div></span><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Rui,<div><br></div><div>What's the intended advantage for compressing the debug sections? - (i) Improved link time through smaller IO / (ii) Improved Load / startup time for the debugger / (iii) Smaller exe with debug info for distribution / disk space?</div></div></blockquote><div><br></div></span><div>I think (1) is definitely the case, and that's also true for a distributed build system with which a lot of object files are copied between machines.</div><div><br></div><div>I doubt (2) is true. Does compressing debug sections improve debugger load time? Of course, as you mentioned, it depends on the ratio of CPU speed and IO speed, but since linked debug info isn't as large as the total of input files, I think it is at least less important than (1).</div><div><br></div><div>As to (3), in most cases, I believe it is rare to distribute executables with debug info widely. Only developers need debug info.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>For i) and ii) how much this is worth it depends on balance of storage bandwidth to compression (i) / decompression (ii) bandwidth. For spinning drives it *might* be a win but for SATA and especially PCIe / NVMe SSD it could be a CPU bottleneck? Though we should also bear in mind that compression can be pipelined with writes in i) and debug info loading could be lazy in ii)</div><div><br></div><div>(e.g. for highly compressible data we've generally seen ~10MiB/s output bandwidth on single thread i7 @3.2GHz memory to memory for zlib9 with 32KiB window, that doesn't stack up well against modern IO)</div><div><br></div><div>How is the compression implemented in lld? Is it chunked and therefore paralellizable (and able to be pipelined with IO) or more serial?</div><div><br></div><div>I think the intention is i) so we'd be happy to link a few of our game titles with varying compression levels vs storage types and let you know the results. Might be a couple of weeks...</div><div><br></div><div>>
<span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I wonder what is the best compression level when -O2 is passed to lld.</span>
</div><div><br></div><div>Just to check, if the default is changed to compress at -O2 we'll still be able to override to disable compression with <span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">-compress-debug-section=none ?</span></div></div></blockquote><div><br></div></span><div>My suggestion was to use compression level 9 when both -O2 and -compress-debug-section=zlib are specified.</div><div><div class="m_8564425474678989059m_-1863218550238759732h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Thanks,</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Simon</span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 2, 2018 at 7:00 AM, via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_8564425474678989059m_-1863218550238759732m_2882837652684607927m_9159179355525773975m_1812745946282140897WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">More data on different compression levels will be good. In this case we're compressing fairly consistent looking input data (a DWARF section) so I think we
stand a good chance of being able to pick a very reasonable level.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I cringe at the thought of yet another user-facing knob, though.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_8564425474678989059_m_-1863218550238759732_m_2882837652684607927_m_9159179355525773975_m_1812745946282140897__MailEndCompose" rel="noreferrer"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>James Henderson via llvm-dev<br>
<b>Sent:</b> Thursday, August 02, 2018 6:32 AM<br>
<b>To:</b> Pavel Labath<br>
<b>Cc:</b> LLVM Dev<br>
<b>Subject:</b> Re: [llvm-dev] Default compression level for -compress-debug-info=zlib?<u></u><u></u></span></p>
</div>
</div><div><div class="m_8564425474678989059m_-1863218550238759732m_2882837652684607927m_9159179355525773975h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Also not an expert, but would it make sense for this to be configurable at a fine-grained level, perhaps with another option, or an extension to the compress-debug-sections switch interface? That way users who care about the finer details
can configure it themselves. And we should pick sensible options for the default.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">James<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 2 August 2018 at 11:08, Pavel Labath via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">I don't claim to be an expert, but I did some zlib compression<br>
benchmarks in the past. IIRC, my conclusion from that was that the<br>
"DEFAULT" zlib level (6) is indeed a very good default for a lot of<br>
cases -- it does not generate much larger outputs, while being<br>
significantly faster than the max level. This all depends on the data<br>
set and what you intend to do with the resulting data, of course, but<br>
I guess my point is you don't have to choose only between 1 and 9. I<br>
think it would be interesting to at least get the data for the default<br>
level before making choice.<br>
<br>
cheers,<br>
pl<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 2 Aug 2018 at 01:57, Rui Ueyama via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Folks,<br>
><br>
> I'd like to get expert's opinion on which compression level is suitable for lld's -compress-debug-section=zlib option, which let the linker compress .debug_* sections using zlib.<br>
><br>
> Currently, lld uses compression level 9 which produces the smallest output in exchange for a longer link time. My question is, is this what people actually want? We didn't consciously choose compression level 9. That was just the default compression level
for zlib::compress function.<br>
><br>
> For an experiment, I created a patch to use compression level 1 instead of 9 and linked clang using that modified lld. By default, lld takes 1m4s to link clang with --compress-debug-sections=zlib. With that patch, it took only 31s.<br>
><br>
> Here is a comparison of clang executable size with various configurations:<br>
><br>
> no debug sections: 275 MB<br>
> level 9 compression: 855 MB<br>
> level 1 compression: 922 MB<br>
> no compression: 2044 MB<br>
><br>
> Given that the best compression takes significantly longer time than the fastest compression, we probably should change the default to level 1. Any objections?<br>
><br>
> I wonder what is the best compression level when -O2 is passed to lld. We could use level 9 when -O2 is passed, but is there any reason to compress debug sections that hard in the first place?<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div>
</blockquote></div></div></div>