Would you consider passing along the compile flag /MP (Multi.Processor Compilation) to C/C++ projects? It can shorten compile times a lot. For CMake projects you just need to append " /MP" to "CMAKE_C[XX]_FLAGS".
bjornpiltz
All 7 comments
You can also specify max n processes with /MPn.
bjornpiltz
on 8 Dec 2016
I thought we already did this. Long term I think people want to switch to using ninja to build if possible.
barcharcraz
on 9 Dec 2016
We throw the MSBuild /m switch which builds projects in parallel, but we don't throw cl.exe's /MP switch which builds files _within_ a project in parallel. An unfortunate situation with MSBuild's C++ support today is that these two switches don't talk to each other: on an N processor machine, throwing both will potentially spawn N^2 processes. On quad core machines, this doesn't regress throughput _too_ badly (it just eats a bunch more RAM), but on higher core servers it can really start to cause problems.
Switching to Ninja for desktop builds solves this issue most soundly because Ninja looks inside each project build and will schedule down to the file level. Therefore, I think it's probably best to channel effort towards that move instead of tweaking combinations of /MPn and /m.
ras0219-msft
on 9 Dec 2016
While we're at compiler flags, wouldn't it be beneficial to use /GL switch in release builds?
codicodi
on 13 Dec 2016
Is this information about MSBuild /m up to date? My builds seem to be strictly sequential. Some projects utilize all cores, while some are strictly single threaded. GDAL, for instance, takes 48 minutes to build on a powerful build machine - not counting dependencies. It would speed things up a lot to throw in /MP there.
bjornpiltz
on 26 Oct 2017
Is this information about MSBuild /m up to date? My builds seem to be strictly sequential. Some projects utilize all cores, while some are strictly single threaded. GDAL, for instance, takes 48 minutes to build on a powerful build machine - not counting dependencies. It would speed things up a lot to throw in /MP there.
Looking at this line it seems that the info is up-to-date.
However, the compilation with VS is still really slow. It took me almost 5 hours to compile OpenCV with QT and CUDA feature (QT and CUDA were already installed).
claudiofantacci
on 9 Jan 2018
This issue hasn鈥檛 been updated in two year, if it is still an issue, please reopen.
LilyWangL
on 28 May 2020
Related issues
pkeir
路
3Comments
madkoala
路
3Comments
jasjuang
路
3Comments
invy
路
3Comments
jack17529
路
3Comments
Most helpful comment
We throw the MSBuild /m switch which builds projects in parallel, but we don't throw
cl.exe's /MP switch which builds files _within_ a project in parallel. An unfortunate situation with MSBuild's C++ support today is that these two switches don't talk to each other: on anNprocessor machine, throwing both will potentially spawnN^2processes. On quad core machines, this doesn't regress throughput _too_ badly (it just eats a bunch more RAM), but on higher core servers it can really start to cause problems.Switching to Ninja for desktop builds solves this issue most soundly because Ninja looks inside each project build and will schedule down to the file level. Therefore, I think it's probably best to channel effort towards that move instead of tweaking combinations of
/MPnand/m.