<div dir="ltr"><div><div>Hi, sorry for the slight delay. Sorta-related to the subject, I had a go doing a full from scratch build a while ago trying to see what components took the time on Linux, using a wrapper around the compiler calls to track the user and system time for each command. I didnt' get any further than looking at the distribution of the build times, but it was the classic thing of a small fraction of the files taking up to 10 times longer than the median. (These were pretty much files in the clang Sema* hierarchy, which is plausible since C++ et all have so many odd rules I'd expect semantic analysis to be lots of non-optimizable code.) Unfortunately there curve was sufficiently smooth without any noticeable "knee" so it didn't look like there was much point trying to choose some cut-off for the longest-compile files and try to refactor them.<br>
<br></div>Anyway, the upshot of that is that I'd expect that raw speed of machine would have more effect than number of cores on an incremental rebuild (at least if the clang subtree has modifications).<br><br></div>Not sure that really helps, but might be interesting info,<br>
<br>Cheers,<br>Dave<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 31, 2013 at 8:52 PM, Anton Yartsev <span dir="ltr"><<a href="mailto:anton.yartsev@gmail.com" target="_blank">anton.yartsev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 30.03.2013 6:51, NAKAMURA Takumi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anton, FYI, one of my builders can build clang by 5 to 6 minutes (with<br>
just-built-clang w/o Assertions).<br>
<a href="http://bb.pgr.jp/builders/clang-3stage-x86_64-linux/builds/112" target="_blank">http://bb.pgr.jp/builders/<u></u>clang-3stage-x86_64-linux/<u></u>builds/112</a><br>
It is; AMD FX-8350, 32GB of RAM and Intel X25-M G2 SSD, Linux x86-64.<br>
<br>
I know it will be faster with more expensive box. Working in progress...<br>
<br>
I strongly suggest you may throw away Windows out of the window :p<br>
Otherwise, I suggest you may take cmake and ninja for (mingw32|msvc).<br>
They work better. Feel free to ask.<br>
</blockquote></div>
I am feeling next to it - no one of 'make' ports I tried (Compiled from the MSYS trunk, Migw32, Migw64, TDM-GCC) handle multiple jobs correctly.<br>
There is likely an old bug causing make to freeze randomly when -jN with N>1 is passed to it. (I found reports with similar problem in MinGW mailing list (<a href="http://sourceforge.net/mailarchive/message.php?msg_id=29801391" target="_blank">http://sourceforge.net/<u></u>mailarchive/message.php?msg_<u></u>id=29801391</a>)<br>

the possible reasons, but no workaround; even found a patch from a user that should fix this, but got another errors when used 'make', compiled with this patch).<br>
<br>
A good idea, thanx! I'll try to use cmake instead of configure. May it produce makefiles that mingw32-make.exe from MinGW64 accept.<br>
mingw32-make.exe is my last hope on a simple solution, but currently it ends up with (renamed mingw32-make.exe to make.exe) :<br>
<br>
make -j8 ONLY_TOOLS="clang" ENABLE_OPTIMIZED=1<br>
Makefile:141: /f/llvm_COMMON/Makefile.rules: No such file or directory<br>
make.EXE: *** No rule to make target `/f/llvm_COMMON/Makefile.<u></u>rules'.  Stop.<br>
<br>
, while 'make' from MSYS build without errors (but hangs randomly).<br>
<br>
MS2012 builds+tests for 20 minutes, but I want MinGW to also work :)<br>
Morover, it produces Clang, that is unable to link files due to unresolved externals.<br>
(the problem is likely related to name mangling issues <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014655.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-dev/2011-April/<u></u>014655.html</a>)<br>

<br>
and that's that!<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
...Takumi<br>
<br>
2013/3/29 Anton Yartsev <<a href="mailto:anton.yartsev@gmail.com" target="_blank">anton.yartsev@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all!<br>
<br>
I have finally decided to upgrade from my old Core 2 Duo E8500, 6GB DDR2 400<br>
MHz.<br>
Currently the full building+testing of llvm lasts for hours (slightly faster<br>
with VS2008, slightly slower with MinGW) and makes everything lag.<br>
Ideally would be happy to perform build+test for about 10-20 minutes, as<br>
some fast builders do, and have no lags with other useful applications, such<br>
as browsers and Acrobat, during building/testing.<br>
Please can anybody advise me an appropriate hardware? Or just tell, what<br>
hardware the fast buildbots are running (specifically<br>
clang-native-mingw64-win7, clang-x86_64-ubuntu-gdb-75 and<br>
clang-x86_64-debian-fast)?<br>
<br>
--<br>
Anton<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></blockquote>
<br>
<br>
-- <br>
Anton<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>cheers, dave tweed__________________________</div><div>high-performance computing and machine vision expert: <a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a></div>
<div>"while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot</div><div> </div>
</div>