<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 1:56 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.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"><div dir="ltr"><div>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><div class="gmail_extra">
<div class="gmail_quote"><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"><div>On 19 Jul 2013, at 09:08, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">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><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> </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"><div>
> 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><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> </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"><div>
> 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>

<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></div></div></blockquote><div><br></div><div>I have very little experience with distributed build systems, so I'm clueless about this, but do most distributed build systems offer a shared, writable filesystem? If not, then `--update-compilation-db=/my/compildation/db/path` seems to not be a viable solution.</div>

<div><br></div><div>-- Sean Silva</div></div></div></div>