1

I noticed earlier that when my VS is building my big c++ solution, my CPU usage was less than 25%. Wondering if I can set VS to always use 100% CPU, I did some research:

Found two options that can be configured for this purpose:

  • Maximum Number Of Parallel Project Builds

enter image description here

  • Maximum Concurrent C++ Compilations

enter image description here

What is the difference?

And to achieve my goal, bonus question is how can I set VS to use more CPU when it builds?

Sandra K
  • 1,209
  • 1
  • 10
  • 21
  • The first setting is about projects. The second setting is about individual translation units. – drescherjm Aug 15 '18 at 18:52
  • @drescherjm So if I set 12 projects, and 4 compilations, will it build 12 projects at the same time, 4 files per project? Total of 4x12 files – Sandra K Aug 15 '18 at 18:54
  • BTW, things have improved over the years however I still have long periods of building that has the CPU no where near 100%. However I believe a lot of this is related to moc (buinding c++ Qt projects). – drescherjm Aug 15 '18 at 18:54
  • 1
    ***So I set 12 projects, and 4 compilations, will it build 4 files per project and 12 projects at the same time, total of 4x12 files simultaneously?*** I don't think you want to change the second setting. I believe 0 means unlimited. – drescherjm Aug 15 '18 at 18:55
  • 1
    To increase parallelism in your build, step one is to try to reduce dependencies between your modules. There's no "magic" setting that can do that for you, just hard work/refactoring. – Jesper Juhl Aug 15 '18 at 18:57
  • 1
    I fully agree with that. Dependencies between projects cause the first setting to not be used to its maximum. – drescherjm Aug 15 '18 at 18:58
  • @drescherjm "I believe a lot of this is related to moc " - with a sufficiently recent Qt (using 5.11.1 here) and a sufficiently recent cmake (3.11.2+) and a sufficiently recent ninja, you can get moc to run in parallel with the rest of your build quite nicely (modulo hard dependencies on the output of course). – Jesper Juhl Aug 15 '18 at 19:03
  • I am using CMake but have not tried ninja yet. – drescherjm Aug 15 '18 at 19:05
  • 2
    @drescherjm You should. It blows both msbuild and make out of the water. Especially versions from within the last 6-8 months. – Jesper Juhl Aug 15 '18 at 19:07
  • 1
    @drescherjm : be sure to use [AUTOMOC](https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html) in your CMakeLists.text files with cmake 3.11.2 and newer (they made some very nice parallelism improvements in 3.11 and 3.11.2 fixed some annoying bugs in that regard). – Jesper Juhl Aug 15 '18 at 19:21
  • Thanks. I don't think we should further the discussion on this point since we may be drifting off topic of the question. @SandraK did not mention Qt. – drescherjm Aug 15 '18 at 19:40
  • @SandraK for code to solve problem posed in your ( deleted ) question https://stackoverflow.com/q/52046650/16582 please see https://ideone.com/hst1zw – ravenspoint Aug 27 '18 at 22:38
  • @ravenspoint Guardian angel ! Got it, would you like me to reopen the question and post the answer? I am fine both ways – Sandra K Aug 28 '18 at 01:04
  • @SandraK I don't know why you closed it, just as as I was finishing the code. So, your call. – ravenspoint Aug 28 '18 at 01:27
  • @ravenspoint It seems like I have not tried anything and will get closed/down voted. I reopened now. Thanks again ! – Sandra K Aug 28 '18 at 01:39

1 Answers1

1

It can often be insightful to see all the files considered in a build. It's not uncommon to access 10.000 files, especially when using bigger libraries.

The fastest way to access these files would be if they're in RAM already, i.e. the OS file cache. Otherwise, an SSD is a reasonable alternative. But if they have to come from a mechanical HDD, the CPU will spend a large amount of time just sleeping while it waits for files to be read.

Hence, the way to improve CPU utilization is to make sure it's not waiting for I/O. Hardware is much cheaper than C++ programmers; get a fast SSD and sufficient RAM.

MSalters
  • 173,980
  • 10
  • 155
  • 350