29

Are there any disadvantages, side effects, or other issues I should be aware of when using the "Multi-processor Compilation" option in Visual Studio for C++ projects? Or, to phrase the question another way, why is this option off by default in Visual Studio?

JBentley
  • 6,099
  • 5
  • 37
  • 72

4 Answers4

22

The documentation for /MP says:

Incompatible Options and Language Features
The /MP option is incompatible with some compiler options and language features. If you use an incompatible compiler option with the /MP option, the compiler issues warning D9030 and ignores the /MP option. If you use an incompatible language feature, the compiler issues error C2813then ends or continues depending on the current compiler warning level option.
Note:
Most options are incompatible because if they were permitted, the concurrently executing compilers would write their output at the same time to the console or to a particular file. As a result, the output would intermix and be garbled. In some cases, the combination of options would make the performance worse.

And it gives a table that lists compiler options and language features that are incompatible with /MP:

  • #import preprocessor directive (Converts the types in a type library into C++ classes, and then writes those classes to a header file)
  • /E, /EP (Copies preprocessor output to the standard output (stdout))
  • /Gm (Enables an incremental rebuild)
  • /showIncludes (Writes a list of include files to the standard error (stderr))
  • /Yc (Writes a precompiled header file)

Instead of disabling those other options by default (and enabling /MP by default), Visual Studio makes you manually disable/prevent these features and enable /MP.

Cornstalks
  • 37,137
  • 18
  • 79
  • 144
12

From our experience the main issues found were:

  1. browse information failing to build due to multiple projects calling bscmake at the same time (useless information nowadays so should be removed as a project setting)
  2. linker failures due to dependency issues and build order issues, something you would not normally see when building normally
  3. Batch builds do not take advantage of multi-processor compilation, at least this was certainly true for 2005-2008 VS editions
  4. warnings generated about pre-compiled headers being incompatible, this occurs when you build stdafx and can be ignored but when doing a rebuild it generates this message

However, the above are configuration issues which you can resolve, otherwise it should be enabled as it will speed up builds.

EdChum
  • 376,765
  • 198
  • 813
  • 562
  • When you say "linker failures", were these problems you saw with regards to the parallel project builds or with regards to the /MP switch, that will do parallel compilation withing one project? (also see [here](http://blogs.msdn.com/b/visualstudio/archive/2010/03/08/tuning-c-build-parallelism-in-vs2010.aspx).) Or were the linker failures due to wrongly configured dependencies? – Martin Ba Dec 19 '13 at 17:58
  • 2
    @MartinBa these were due to project dependencies not being set correctly in the solution, if you didn't enable parallel project builds then you sometimes got away with it, with larger and more complicated solutions you invariable got a linker error and had to hunt through the output to find the offending project(s) – EdChum Dec 19 '13 at 18:00
6

Because multi-processor compilation isn't compatible with many other compilation options and also has higher usage of system resources. It should be up to the developer to decide whether or not it's worth for him. You can find the full documentation here: http://msdn.microsoft.com/en-us/library/bb385193.aspx

SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85
  • "Higher usage of system resources" can be important - I've had template-heavy projects tying up a reasonably powerful desktop machine to such an extent that it doesn't respond to mouse movement or keystrokes for ten minutes at a time. Cured by disabling multiprocessor compilation - with only a modest increase in build times, offset by actually being able to use the machine for other activities while building. – Jeremy Jun 23 '17 at 09:56
1

While using /MP will bring some benefit to the compilation speed, there is still some performance left on the table due to the way workload is scheduled: https://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

The compiler receives jobs in "batches" (a set of source files passed to compiler) and will only start the next batch when the prior one is finished. That means there are cycles left unused on other cores until the longest translation unit is compiled. There is no sharing of data between the compiler subprocesses.

To improve utilization on multiple cores even further I suggest switching to ninja. I've implemented it in a few projects and it was always a win, e.g. https://github.com/openblack/openblack/pull/68#issuecomment-529172980

janisozaur
  • 842
  • 7
  • 10