Hello,<div><br></div><div>I noticed this project at open project web page and read previous posted thread.I am </div><div>a master degree student and want to do a project related to LLVM/Clang as my master </div><div>thesis. My goal is not just accomplishing my thesis but also contributing to LLVM </div>
<div>community.</div><div><br></div><div>I am curious about the following:</div><div><br></div><div>I have tried distcc and find distcc works well with clang. However distcc use gcc as</div><div>an external program. It is inefficient for Clang because Clang is library-based. Is this the </div>
<div>reason to develop a new distcc?</div><div><br></div><div>Ching</div><div><br><div class="gmail_quote">2012/6/17 Lyu Mitnick <span dir="ltr"><<a href="mailto:mitnick.lyu@gmail.com" target="_blank">mitnick.lyu@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jun 16, 2012 at 9:14 PM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

><br>
> On Sat, Jun 16, 2012 at 8:36 PM, Matthieu Monrocq <<a href="mailto:matthieu.monrocq@gmail.com">matthieu.monrocq@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Sat, Jun 16, 2012 at 3:19 PM, Lyu Mitnick <<a href="mailto:mitnick.lyu@gmail.com">mitnick.lyu@gmail.com</a>> wrote:<br>
>>><br>
>>> Hello Douglas,<br>
>>><br>
>>> I have read all posted carefully. According to the discussion, what we<br>
>>> can do better than<br>
>>> original distcc are as follows:<br>
>>><br>
>>> 1) The intermediate files passed over the network would be serialized AST<br>
>>> 2) The intermediate files passed over the network would be LLVM IR<br>
>>> 3) Centralized admin daemon<br>
>>> 4) Use PCH<br>
>>><br>
>>> To improve the issues above. We can extend the original distcc.<br>
>>> However Chris Lattner<br>
>>> mentioned the first mile-stone of clang distributed build project is<br>
>>> re-implementing a new<br>
>>> distcc.<br>
>>><br>
>>> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-April/001357.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-April/001357.html</a><br>
>>><br>
>>> I am wondering to know why and what is the desired design of clang<br>
>>> distributed build<br>
>>> project for cfe community.<br>
>>><br>
>>> Mitnick<br>
>>><br>
>>> ><br>
>>> > No, this project has not been accomplished. I don't think there was any real progress on it since that discussion.<br>
>>> ><br>
>>> >        - Doug<br>
>>><br>
>><br>
>> We have been using distcc (on top of gcc) for a while at work, and it does work, somewhat, but it has a big issue: preprocessing is a huge part of compilation, not being able to get rid of it creates a bottleneck that inhibits true scalability. Given that we are using 24 cores servers, we could push to about 40/60 parallel compilations (interesting when an error occurs in a header and the local machine has to compile those 40/60 files locally to display the errors); any further and we would not observe any significant progress in compilation time: the local machine became the bottleneck.<br>

>><br>
>><br>
>> We experimented for a time with a solution where we streamed the raw unprocessed files and had a filtering in place to only push "local" files and have replica on the distcc hosts for the 3rd party headers. It worked quite well, not much gain but slightly faster... as long as the distcc host had the up-to-date collection of 3rd party headers & the local directory hierarchy was similar; had a few issues with it (maintenance) so we fell back to the traditional distcc.<br>

>><br>
>> Honestly, we got much more performance boost from ccache than from distcc.<br>
>><br>
>> I am unsure how to work around the local preprocessing issue, and I am afraid that no significant progress will be made as long as it stands in the way. I would be glad to hear some folks have ideas to get around it, these days I put more hope in a "persistent" process that would cache various stages of the compilation pipeline (maybe using the daemon Chandler was talking about ?).<br>

><br>
><br>
> clangd is not about speeding up distributed compilations - I'm not sure I understand what the problems were you ran into with your distributed build that pushed the "raw" files, but with enough caching you can save considerable time and processing power that way [1]. Hopefully modules will pave the way for an even better distributed C++ build. Well, and better linkers...<br>

><br>
> [1] <a href="http://google-engtools.blogspot.de/2011/09/build-in-cloud-distributing-build-steps.html" target="_blank">http://google-engtools.blogspot.de/2011/09/build-in-cloud-distributing-build-steps.html</a><br>
><br>
><br>
<br>
My point was that maybe distributed compilation is not what we should<br>
be aiming for. Modules-based languages such as Java don't have such<br>
issues because they don't spend their time<br>
lexing/preprocessing/parsing the same headers over and over; they are<br>
amenable to saving up the evaluated AST of a module. C++ developers<br>
have often dreamt, even without modules, that perhaps a sufficiently<br>
smart compiler process could manage this for header files... the myth<br>
of the C++ compilation server.<br>
<br>
Anyway, I think that clangd could be part of the solution. When using<br>
Java with Eclipse, the files are compiled in the background, so you<br>
have to wait less. We could imagine the same possibility with clangd:<br>
an option so that when the file passes -fsyntax-only, the daemon<br>
generate the associated .o.<br>
<br>
It's not the same idea that distributed compilation, but distributed<br>
compilation is more about rebuilding from scratch I think, and people<br>
kinda expect that a build from scratch be long. It's the incremental<br>
re-compilation that is a pain (when you are working) and I believe<br>
clangd would be amenable for speeding this up... though it's maybe a<br>
little early.<br>
<br>
-- Matthieu<br>
</blockquote></div><br></div>