How to Turn on Multi-Cpu/Core C++ Compiles in the Visual Studio Ide (2008)

How do I turn on multi-CPU/Core C++ compiles in the Visual Studio IDE (2008)?

To enable /MP option you could add it to Project Settings->C/C++->Command Line|Additional options. This is the only way to switch it on in vcproj.

Was Visual Studio 2008, 2010 or 2012 (v11) written to use multi cores?

I think you're probably better off with a higher-clock dual core. I think VS (and most apps today) do not yet take great advantages of multi-threading. VS may have dozens of threads running, but only a subset of operations really take advantage of them well I think. A whole lot of the VS implementation is C++ COM components that run on the STA thread, so the UI thread does the bulk of the work in many scenarios. The fact that many pieces of the VS shell are being rewritten in managed code as part of VS2010 will help break a lot more of these ancient component STA dependencies. As others have mentioned, some key scenarios (like building a large solution) already do take advantage of multiple cores (MSBuild works well in parallel), so if those dominate what you care about, then more cores is better. But for things like IDE UI usage and background compilation, I think most of these are still mostly single-threaded. I've a quad-core box at work, and I rarely see VS2008 use more than 25% of my CPU resources. (I've not used VS2010 enough in earnest to know which scenarios are better, though I know at least a few are better.)

Can MS Visual Studio compile projects using 2 or 4 cores on CPU?

You can if you setup an external tool pointing to MsBuild to build the solution with the multiple process flag /m.

Scott Hanselman wrote a nice post on how to accomplish this, so I won't repeat what he has already done.

Are there any disadvantages to multi-processor compilation in Visual Studio?

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.

Will more CPUs/cores help with VS.NET build times?

MSBuild (which VS uses to do builds, from 2005/.NET2) supports parallel builds. By default VS will set the maximum degree of parallelism to your number of processors. Use Tools | Options | Projects and Solutions | Build and Run to override this default.

Of course any one build might have more limited (or no) capacity to allow parallel builds. E.g. only one assembly in a solution provides no scope to build in parallel. Equally a large number of assemblies with lots of dependencies might block parallelism (A depends on B, C depends on A&B, D depends on C has no scope for parallel builds).

(NB. for C++, in VS 2005 & 2008 uses its own build system, in 2010 C++ will also be built with MSBuild.)

How to improve Visual C++ compilation times?

One thing that slows down the VC++ compiler is if you have a header file that initializes concrete instances of non-trival const value types. You may see this happen with constants of type std::string or GUIDs. It affects both compilation and link time.

For a single dll, this caused a 10x slowdown. It helps if you put them in a precompiled header file, or, just declare them in a header and initialize them in a cpp file.

Do take a look into the virus scanner, and be sure to experiment with precompiled headers, without it you won't see VC++ at its best.

Oh yeah, and make sure the %TMP% folder is on the same partition as where your build is written to, as VC++ makes temp files and moves them later.