russell.gallop added a comment.

In D69825#1758949 <https://reviews.llvm.org/D69825#1758949>, @aganea wrote:

> Thanks for the feedback Russell!
>
> Can you possibly try again with `/MT`? (ie. `-DLLVM_USE_CRT_RELEASE=MT`)


I tried adding this to my stage 1 builds and it didn't make any significant 
difference (times in seconds):

No patch (573.879, 568.519, 567.709)
With Patch (578.253, 558.515, 562.368)

In case it makes a difference, this is from a VS2017 command prompt with Visual 
Studio 15.9.17.

> In the `abba_test.ps1` script, `ninja check-all` is only used for preparing 
> clang.exe with the patch. The A/B loop //does not// use `check-all`.

Ah, yes. Sorry, my mistake.

> I also found out that on some of our multi-socket servers, Ninja defaulted to 
> only the # threads from the first socket. If you had a 2x 18-core system, 
> Ninja would default to 38 threads (18 x 2 + 2) instead of 74 threads (2 x 18 
> x 2 + 2). This behavior seems to be random,  depending on the system. This 
> has been fixed by Ninja PR 1674 
> <https://github.com/ninja-build/ninja/pull/1674>, I've tested all our systems 
> with this patch and they now all default to the proper # of threads.

I'm not testing on a multi-socket system so don't believe I need that patch.

> I'm doing a new round of tests, I'll get back with updated figures.

Thanks.

I ran the new version of abba_test.ps1 (just building LLVM) with small 
modifications to comment out the "Validate Ninja" step and change "check-all" 
to "all" to save time as I'm concentrating on build build speed. This means 
that I'm applying it to the same git revision as you. For 
clang_bypass_cc1.patch I used the patch I downloaded before (before spinning 
off D70568 <https://reviews.llvm.org/D70568>). Running for one hour on a six 
core machine (winver 1803, 14 ninja jobs, CFG enabled, recently rebooted) I get:

  Total iterations:  2
  
       |         Min       |        Mean       |       Median      |         
Max       |
     A |  00:15:13.0773389 |  00:15:13.7219710 |  00:15:13.7219710 |  
00:15:14.3666030 |
     B |  00:15:08.6134425 |  00:15:09.0363284 |  00:15:09.0363284 |  
00:15:09.4592142 |
  Diff | -00:00:04.4638964 | -00:00:04.6856426 | -00:00:04.6856426 | 
-00:00:04.9073888 |

So in this case it saved 0.5% of time. Using the previous maths, with 2378 
clang-cl jobs, this implies process creation time of 29ms. This was fairly soon 
after a reboot. Maybe I'm just lucky and none of the process creation problems 
are affecting me on this system (at this moment).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69825/new/

https://reviews.llvm.org/D69825



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to