<div dir="ltr">On Fri, Jul 19, 2013 at 10:27 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<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"><div class="im">On 19 Jul 2013, at 09:08, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

<br>
> Well, for example, we can spawn a process that writes to the compilation db in the background from the driver, and if we assume that C++ compilations are long compared to writing a line of text to a file, we get that:<br>

<br>
</div>So now we get the extra overhead of another fork / exec.  Lots more TLB churn, which is often a limiting factor on scalability on modern CPUs.<br></blockquote><div><br></div><div>I think when we're talking C++ compilations everything else is dwarfed by the CPU use of re-parsing transitive include closures.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> a) finishing off the build will be independent of finishing writing to the compilation db, thus, the impact on the build is negligible<br>
<br>
</div>Other than having twice as many processes running...<br></blockquote><div><br></div><div>clang already spawns a subprocess per clang invocation by the driver. If that significantly impacted build performance, I'm sure that somebody would have changed that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> b) the compilation db will probably be finished writing before the build finishes (as each step probably finishes writing to the compilation db before the step finishes)<br>
<br>
</div>Yes, the 'probably' bit is fun here.  If your build system is doing the 'run the tool' step as a dependency of the build step, you end up with this sequence (for -j n):<br>
<br>
n compilation tasks finish.<br>
Build system starts tool.<br>
Tool acquires lock on compilation database and runs.<br>
n child processes of the compile sit waiting for the lock.<br>
Tool finishes.<br>
n child processes sequentially update compilation database<br>
<br>
Even better, some of them will probably succeed, so not only do you have the wrong data in the compilation database, you have inconsistent and wrong data in the compilation database.<br></blockquote><div><br></div><div>I'm not sure we're talking about the same implementation idea. The whole idea would be to not have anything special in the build system, but to specify an --update-compilation-db=/my/compildation/db/path flag. Then the driver would take that flag, and launch a background task to update that file.</div>
<div><br></div><div>Thus, it would be:</div><div>build system launches clang</div><div>clang launches:</div><div>-> launches the compilation db update process<br></div><div>-> launches the clang -cc1 process</div><div>
with high probability the tool finishes before clang -cc1 process finishes, as C++ compilation takes a lot longer than writing to a single file (for example build disk I/O is also competing for a common resource, parsing CPU is a common resourc, and there are dependencies inherent in the build, which make it not fully parallelizable)</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>