<div dir="ltr">On Sat, Dec 3, 2016 at 5:35 PM, Rui Ueyama via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Modified: lld/trunk/ELF/Threads.h<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Threads.h?rev=288606&r1=288605&r2=288606&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/lld/trunk/ELF/Threads.<wbr>h?rev=288606&r1=288605&r2=<wbr>288606&view=diff</a><br>
==============================<wbr>==============================<wbr>==================<br>
--- lld/trunk/ELF/Threads.h (original)<br>
+++ lld/trunk/ELF/Threads.h Sat Dec  3 17:35:22 2016<br>
@@ -6,6 +6,54 @@<br>
 // License. See LICENSE.TXT for details.<br>
 //<br>
 //===-------------------------<wbr>------------------------------<wbr>---------------===//<br></blockquote><div><br></div><div>Great comment...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+//<br>
+// LLD supports threads to distribute workloads to multiple cores. Using<br>
+// multicore is most effective when more than one core are idle. At the<br>
+// last step of a build, it is often the case that a linker is the only<br>
+// active process on a computer. So, we are naturally interested in using<br>
+// threads wisely to reduce latency to deliver results to users.<br>
+//<br>
+// That said, we don't want to do "too clever" things using threads.<br>
+// Complex multi-threaded algorithms are sometimes extremely hard to<br>
+// justify the correctness and can easily mess up the entire design.<br>
+//<br>
+// Fortunately, when a linker links large programs (when the link time is<br>
+// most critical), it spends most of the time to work on massive number of<br>
+// small pieces of data of the same kind. Here are examples:<br>
+//<br>
+//  - We have hundreds of thousands of input sections that need to be<br>
+//    copied to a result file at the last step of link. Once we fix a file<br>
+//    layout, each section can be copied to its destination and its<br>
+//    relocations can be applied independently.<br>
+//<br>
+//  - We have tens of millions of small strings when constructing a<br>
+//    mergeable string section.<br>
+//<br>
+// For the cases such as the former, we can just use parallel_for_each<br>
+// instead of std::for_each (or a plain for loop). Because tasks are<br>
+// completely independent from each other, we can run them in parallel<br>
+// without any coordination between them. That's very easy to understand<br>
+// and justify.<br>
+//<br>
+// For the cases such as the latter, we can use parallel algorithms to<br>
+// deal with massive data. We have to write code for a tailored algorithm<br>
+// for each problem, but the complexity of multi-threading is isolated in<br>
+// a single pass and doesn't affect the linker's overall design.<br>
+//<br>
+// The above approach seems to be working fairly well. As an example, when<br>
+// linking Chromium (output size 1.6 GB), using 4 cores reduces latency to<br>
+// 75% compared to single core (from 12.66 seconds to 9.55 seconds) on my<br>
+// machine. Using 40 cores reduces it to 63% (from 12.66 seconds to 7.95<br>
+// seconds). Because of the Amdahl's law, the speedup is not linear, but<br>
+// as you add more cores, it gets faster.<br></blockquote><div><br></div><div>... one very minor nit here: "my machine" doesn't mean much in a shared code base :-)</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"># Meador</div>
</div></div></div>