[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