Hello,
Just wanted to start a conversation around the default value of CMAKE_CXX_MP_FLAG on MSVC builds. Would there be any objection to setting it to ON?
Adam
Hello,
Just wanted to start a conversation around the default value of CMAKE_CXX_MP_FLAG on MSVC builds. Would there be any objection to setting it to ON?
Adam
This has been discussed in the past, see http://slicer-devel-archive.65872.n3.nabble.com/Reducing-Slicer-build-time-on-Windows-using-CMAKE-CXX-MP-FLAG-td4035926.html
@adamrankin How much does it reduce the build time for you?
As I remember, there were some potential issues in parallel builds - but maybe it was about parallel execution of test. @jcfr is there any risk or disadvantage of enabling parallel builds?
I have not quantified it, but it is noticeable. Is it worth me quantifying it in addition to your results?
Edit: it will be more and more noticeable with the introduction of higher and higher multicore count (see Ryzen Threadripper 16 core).
From here
/MP – Parallelize compilation of source files
Invokes multiple instances of cl.exe to compile project source files in parallel. See documentation for /MP for a detailed discussion of the switch including conflicts with other compiler features. In addition to documentation this blog post has good information about the switch.Resolving conflicts with other compiler features
/Gm (enable minimal rebuild): I recommend using /MP over /Gm to reduce build time.
#import: Documentation for /MP discusses one option to resolve this conflict. Another option is to move all import directives to precompiled header.
/Yc (create precompiled header): /MP does not help with creating precompiled header so not an issue.
/EP, /E, /showIncludes: These switches are typically used to diagnose issues hence should not be an issue.
Depending on the incompatibility:
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 C2813 then ends or continues depending on the current compiler warning level option.
The flag is set to do the nightly build. See https://github.com/Slicer/DashboardScripts/blob/4efec4e330f4e79da9d9eef3ac445a350bde4618/overload-vs2013-slicer_release_nightly.cmake#L57
Since having four cores (or more) is fairly common, may be we could make this the default ?
The problem I’ve seen with ninja (mac) is nested external project builds. For example, building with -j4
at the superbuild level means potentially four top-level projects can build in parallel. But when the flag is passed to the child process, in ninja each one of those tries to use four cores so the computer ends up swapping/thrashing. I don’t know if msbuild
is susceptible to such an issue.
(there is a “job pool” concept in GNU make, and now available in ninja, to avoid this problem)