<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 2:29 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5">On Fri, Jul 19, 2013 at 11:14 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</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 dir="ltr"><div>On Fri, Jul 19, 2013 at 2:08 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 19 Jul 2013, at 10:01, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>



<br>
> There is no need to have it be a separate process at all. Just start a background thread and join it before terminating.<br>
<br>
</div>Have you benchmarked the difference between clang with and without pthreads linked in?  A lot of libc and STL things become more expensive (including malloc(), although not by much) when pthreads are linked, even if they're not used.</blockquote>


<div><br></div></div><div>Yes, I have, and on my systems none of these things are true. I don't know whether or why they are true for you, but I don't think it should guide the decision of how to architect the Clang driver.</div>


<div><br></div><div>In the not too distant future we will almost certainly want to build Clang as a multithreaded binary (if possible to do so) so that we can take advantage of threads internally.</div><div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  These may be dwarfed by the CPU time of the compilation, but it isn't free.<br></blockquote><div><br></div></div><div>Sure, it isn't free. I'm not suggesting that it is. But I am suggesting that it is a totally viable fallback strategy for this use case, and that the cost is negligible while still being non-zero.</div>


</div></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">+1. I hope I didn't sound like I was suggesting it was free :) Adding code is never free.</div><div class="gmail_extra">The important question is whether it's actually affecting the bottom line in a measurable way (which I think it won't).</div>

<div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>As a simple test of the overhead, I modified the clang driver to (at the beginning of main) open a lock file "/Users/sean/tmp/clang.lock" (in a blocking manner) and write "foo\n" to the file, then close the file. My hardware is a dual socket quadcore xeon mac pro with hyperthreading (2 sockets x 4 cores x 2 threads = 16). I built an LLVM release build (CMake+ninja) with both an unmodified and modified clang.</div>
<div><br></div><div>My findings were that this does not have a noticeable effect on compilation time in this particular setup. Since a blocking locked write is a sort of "worst case", I think that (extrapolating a bit) at least for local builds, the effect of file locking is likely insignificant.</div>
<div><br></div><div>-- Sean Silva </div></div></div></div>