![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/4\/2019\/06\/image_14.png\" "\\"image\\"")
<\/a> <\/p>\nThis dial is just the same as VS2008, although under the covers MSBuild is taking over some of the work from Visual Studio now.<\/p>\n
If you\u2019re building C++ or C++\/CLI, there\u2019s another place you can get build parallelism. The CL compiler supports the \/MP switch, which tells it to build subsets of its inputs concurrently with separate instances of itself. The default number of buckets, again, is the number of CPU\u2019s, but you can also specify a number, like \/MP5. Again, this was available before, so I\u2019m going to just remind you where the value is and what it looks like in the MSBuild format project file.<\/p>\n
Go to your project\u2019s property pages, and to the C\/C++, General page. For now I suggest that you select All Configurations and All Platforms. You can be more selective later if you want.<\/p>\n
As usual you can see what\u2019s in the project file by unloading it, right clicking on the node in the Solution Explorer, and choosing Edit:<\/p>\n Here\u2019s what it looks like in the project file. Yes, it\u2019s inside a configuration and platform specific block, but it put the same value in all of them.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Notice that it\u2019s in an \u201cItemDefinitionGroup\u201d. That MSBuild tag simply indicates it defines a \u201ctemplate\u201d for items of a particular type. In this case, all items of type \u201cClCompile\u201d will automatically have metadata MultiProcessorCompilation with value true unless they explicitly choose a different value.<\/p>\n By the way, MSBuild Items, in case you\u2019re wondering, are just files, usually. Their subelements, if any, are the metadata. Here\u2019s what some look like. Notice they\u2019re in an \u201cItemGroup\u201d:<\/p>\n Because this is metadata, at an extreme, I could actually set this down to a per-file basis. In that case, MSBuild would bucket together all the inputs that have a common value. You would need to disable \/MP for particular files that use #import, for example, because that’s not supported with \/MP. (Other features not supported with \/MP are \/Gm, which is incremental compilation, and a few other switches documented here<\/a>)<\/p>\n Note it\u2019s under the \u201cItemGroup\u201d because these are actual items:<\/p>\n Back to multiprocessor CL. If you want to tell CL explicitly how many parallel compiles to do, Visual Studio lets you do this \u2013 as for \/MP, it’s exposed as a global setting: Under the covers, VS passes this on by setting a property (a global property \u2013 it’s not persisted) named CL_MPCount. That means it won’t have any effect when building outside of VS.<\/p>\n If you want to choose a value at a finer grained level you can\u2019t use the UI as it\u2019s not exposed in the property pages or the command line preview. You have to go into the project file editor and type it. It\u2019s a different piece of metadata on the CLCompile items, named \u201cProcessorNumber\u201d. It can have a number from 1 to as high as you like and adds the numeric value to \/MP if you want it. If you don’t have <MultiProcessorCompilation> it will be ignored.<\/p>\n The squiggle here is a minor bug \u2013 ignore it.<\/p>\n The \/MP settings come from the project files, so they work exactly the same on the command line. That\u2019s part of the whole point of MSBuild, right, the same build on the command line as in Visual Studio? But the global parallelism setting that you set in Tools, Options does not affect the command line. You must pass it yourself to the msbuild.exe command with the \/m switch. Again, the value is optional and if you don\u2019t supply a value it uses the number of CPU\u2019s. However, unlike Visual Studio, out of the box, without \/m supplied, it uses 1 CPU. That might change in future.<\/p>\n To choose the number on any \/MP value, you can set an environment variable, or pass a property, named CL_MPCount, just like Visual Studio does.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Probably you\u2019ll want to use \/MP on more than one of your projects, and you don\u2019t want to edit each individually. The Visual Studio solution to this kind of problem is property sheets. They don\u2019t have any special connection to multiprocessor build, but it\u2019s an opportunity for me to give a quick refresher using this as an example. First open the \u201cProperty Manager\u201d from the view menu. Its exact location will vary depending on the settings you\u2019re using, here\u2019s where it is if you have C++ settings;<\/p>\n Right click on a project and choose \u201cAdd New Property Sheet\u201d:<\/p>\n I have mine the name \u201cMultiprocCpp.props\u201d. You\u2019ll see it gets added to all configurations of this project. Right click on it, and you\u2019ll see the same property pages that the project has, but this time you\u2019re editing the property sheet. Again, set \u201cMulti-processor Compilation\u201d to \u201cYes\u201d. Close the property pages, select the property sheet in the Property Manager, and hit Save. <\/p>\n Now I can open up that new MultiprocCpp.props file in the editor, and I see this:<\/p>\n (Again, ignore the squiggle.)<\/p>\n Looking in the project file, you can see the property sheet pulled in to each configuration, using an \u201cImport\u201d tag. Think of that just like a #include in C++: <\/p>\n So now we have the definition we put in the project file before, but in a reusable form. Given that, I can put it into all the projects I want in one shot, by multi-selecting in the Property Manager and choosing Add Existing Property Sheet:<\/p>\n Now all your projects compile with \/MP !<\/p>\n In some circumstances, you might want to go beyond what you can easily do in the Property Manager. For example you might want to bulk-remove a property sheet, or put a property sheet in each project once outside of all the configurations. Fortunately MSBuild 4.0 has a powerful and complete object model over its files that you can use to do this kind of work in a few lines of code. More on that in a future blog post, but for now, if you want to take a look, point the Object Browser at Microsoft.Build.dll.<\/p>\n Before I leave property sheets, it\u2019s worth mentioning that you can do this kind of common-importing in your own ways, if you don\u2019t mind losing some of the UI support. For example, in the build of VS itself, we pull in a common set of properties at the top of every project, like this example from the project that builds msenv.dll (which contains much of the VS shell)<\/p>\n Within that <\/em>we define all kinds of global settings, and import yet others. I\u2019ll talk about this kind of structure in a future blog post about the organization of large build trees.<\/p>\n Usually the problem is getting enough parallelism to exploit all your machine\u2019s cores. But the reverse problem is possible, and although it\u2019s a nice problem to have, it needs fixing because it will cause your machine to thrash. Here\u2019s what task manager might look like when this is happening:<\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\nWhat about building on the command line?<\/h3>\n
<\/a> <\/p>\nSetting \/MP on every project is tiresome, what are my options?<\/h3>\n
<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\n<\/a> <\/p>\nToo much of a good thing<\/h3>\n