<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 20, 2015 at 5:47 AM, Domagoj Saric <span dir="ltr"><<a href="mailto:domagoj.saric@littleendian.com" target="_blank">domagoj.saric@littleendian.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"><span class="">On 20.5.2015. 13:09, Kim Gräsman 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">
There are two levels of parallellization in Visual Studio/Visual C++;<br>
<br>
1) Machine-wide setting of how many projects to build in parallel --<br>
this informs Visual Studio/MSBuild<br>
2) Compiler setting (/MP) of how many source files to compile in<br>
parallel -- this actually informs CL.EXE and causes it to launch child<br>
processes<br>
<br>
See Bruce Dawson's treatise for the gory details:<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__randomascii.wordpress.com_2014_03_22_make-2Dvc-2Dcompiles-2Dfast-2Dthrough-2Dparallel-2Dcompilation_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=vK3ShwNTZxKygOI4JKjOiPPs4QeF4kE2kGeO6r9xpsM&s=kWL3re3kFa7b21YZbL7WdCSFLy-UrzJTGqvk_lJubaQ&e=" target="_blank">https://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/</a><br>
<br>
Not sure how easy/desirable this behavior would be in clang-cl, but<br>
from a principal standpoint I'd prefer this kind of thing in the build<br>
system, not the compiler.</blockquote></span></blockquote><div><br></div><div>Given that cl implements /MP by simply launching more cl.exe subprocesses that can oversaturate your system if MSBuild is building multiple projects in parallel, I'm not inclined to complicate the driver with parallel execution. If someone put together a particularly elegant and low-maintenance burden patch, though, I think we could take it.</div><div><br></div><div>If Microsoft really wants to squeeze more parallelism out of VS builds, they should expose the in-project compilation parallelism to the build system and let MSBuild handle it.</div><div><br></div><div>If individual users want more parallel builds, I have to recommend that they avoid MSBuild and try to hook VS up to ninja instead.</div><div><br></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">
But from a 'practical standpoint', wouldn't a multithreaded compiler be the faster solution? e.g.:<br>
 - you'd parse precompiled and/or shared headers only once for all the sources being compiled simultaneously/in-parallel<br>
 - multithreaded LTO/LTCG 'for free'<br>
 - threads are cheaper than processes</blockquote><div><br></div><div>When I was an intern, we thought this would be a good idea. We learned, though, that at least for the frontend, nobody actually wants a multi-threaded compiler. This would inevitably lead to threading bugs and non-deterministic diagnostic output and compiler output. You really don't want to use the AST for your last parse of a.h in your next compile or you'll end up not emitting diagnostics that you would've otherwise, and compilations stop being reproducible.</div><div><br></div><div>For basic compilation actions, you really want the safety that process isolation gives you. Windows processes aren't as expensive as people think they are, and on better optimized OSs they are pretty cheap.</div><div><br></div><div>Something like deterministic, multi-threaded LTO would be pretty cool, though.</div></div></div></div>