[PATCH] D52193: RFC: [clang] Multithreaded compilation support
Alexandre Ganea via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 19 06:40:44 PDT 2018
aganea added a comment.
In https://reviews.llvm.org/D52193#1239171, @hans wrote:
> Thanks for adding the Ninja numbers. It confirms that Ninja is significantly faster than MSBuild + /MP.
It is true for the 6-cores Xeon, but not for the dual-18-cores. I think there are two issues there, somehow unrelated to /MP: 1. Invoking the child clang-cl -cc1 for **each** cpp file makes things much slower. I’ve clocked the invocation at about 60-100ms (which is caused mainly by loading dlls & registery accesses). Most likely Reid’s change about delay loading dlls should improve that. 2. The other issue is, I think, the process context switching at the OS-level. This link: https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows&num=4 - shows that multi-threading is significantly faster on a Linux machine, as far as high cores count goes (when compared with the same test ran on the same machine under Windows 10).
> Since that's the case, maybe we should be poking MS about making MSBuild faster instead of adding /MP support to Clang? Or making it easier to use Ninja in VS projects? Your patch says RFC after all :-)
Sad for Microsoft, but at this point it is a _design_ change MSBuild needs. And as a PM I would rather invest in bindings to better build systems (Ninja, Fastbuild). However I expect there are still users of MSBuild out there, and without /MP this means essentially that migrating to clang-cl requires also changing their build system and their VS2017 integration with the said build system.
Repository:
rC Clang
https://reviews.llvm.org/D52193
More information about the cfe-commits
mailing list