<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 9:02 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi ruiu,<br>
<br>
This flattens the entire liveness walk from a recursive mark approach to<br>
a worklist approach. It also sinks the worklist management completely<br>
out of the SectionChunk and into the Writer by exposing the ability to<br>
iterato over children of a chunk and over the symbol bodies of relocated<br>
symbols. I'm not 100% happy with the API names, so suggestions welcome<br>
there.<br>
<br>
This allows us to use a single worklist for the entire recursive walk<br>
and would also be a natural place to take advantage of parallelism at<br>
some future point.<br>
<br>
With this, we completely inline away the GC walk into the<br>
Writer::markLive function and it makes it very easy to profile what is<br>
slow. Currently, time is being wasted checking whether a Chunk isa<br>
SectionChunk (it essentially always is), finding (or skipping)<br>
a replacement for a symbol, and chasing pointers between symbols and<br>
their chunks. There are a bunch of things we can do to fix this, and its<br>
easier to do them after this change IMO.<br>
<br>
This change alone saves 1-2% of the time for my self-link of lld.exe<br>
(which I'm running and benchmarking on Linux ironically).<br>
<br>
Perhaps more notably, we'll no longer blow out the stack for large<br>
links. =]<br>
<br>
Just as an FYI, at this point, I/O is starting to really dominate the<br>
profile. Well over 10% of the time appears to be inside the kernel doing<br>
page table silliness. I think a decent chunk of this can be nuked as<br>
well, but it's a little odd as cross-linking in this way isn't really<br>
the primary goal here.<br></blockquote><div><br></div><div>This is really curious. Are you using huge pages on Linux? I know on Mac I've had workloads that slow down by 4x due to simply due to the cost of faulting in the memory (just minor faults; nothing disk related), since Mac only uses 4K pages. Switching to 2M pages should alleviate that by a factor of 512, unless the memory workload can't make use of 2M pages (e.g. if all the input object files are so small that using a 2M page doesn't really help).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Depends on D10789<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10790&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=LKIeJVpIDxayGuPwGx81QM1qOlOk76r-wLwxdI3-Crg&s=XMI2-TBLPV0idrvgbkdCmGKVEXxgkMjCqAl1FhPxr8g&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10790</a><br>
<br>
Files:<br>
  COFF/Chunks.cpp<br>
  COFF/Chunks.h<br>
  COFF/Symbols.h<br>
  COFF/Writer.cpp<br>
<br>
EMAIL PREFERENCES<br>
  <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_settings_panel_emailpreferences_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=LKIeJVpIDxayGuPwGx81QM1qOlOk76r-wLwxdI3-Crg&s=BhZz4d07Cw2cSJI0B8oEPDnhXaXasR7z9iRu0Z53CPc&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>