I use the latest Intel compiler atop MVS 2013. I am developing a small application which currently consists of a static library with main functionality (9 classes) and an one-file console executable to test the former. I decided to build the application under release configuration to find out how faster it will become.
The problem is while the static library builds rather swiftly producing 13 MB .lib file (that is,as I found out, normal), the executable is taking very long time. I left it overnight and it is still hasn't been finished (currently over 12 hours). There has been no visible progress except mcpcom has been slowly increasing its memory usage to currently 1GB.
The static library compiling settings :
/MP /GS /GA /W3 /Gy /Zc:wchar_t /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "WIN32" /D "NDEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MD /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_library.pch"
The executable compiling options:
/MP /GS /GA /W3 /Gy /Zc:wchar_t /I"C:\Work\MyApplication\MyApplication_library" /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MT /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_test.pch"
linker options
/OUT:"C:\Work\MyApplication\Release\MyApplication_test.exe" /MANIFEST /NXCOMPAT /PDB:"C:\Work\MyApplication\Release\MyApplication _test.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "C:\Work\Speedsim30\Release\MyApplication_Controller.lib" /LTCG:STATUS /MACHINE:X86 /OPT:REF /SAFESEH /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Release\MyApplication_test.exe.intermediate.manifest" /OPT:ICF /NOLOGO /TLBID:1
My personal computer has a powerful hardware configuration with Intel i7-4770K, 8 GB of DDR3-2133, and 2 SSDs in RAID0
thank you in advance
I found out that the problem is in in /MT and /MD mismatch between the library and the executable - i must have misclicked while setting up the release configuration. Correcting it allowed application to build.
Related
There are many posts about how to set the Runtime library in Visual Studio from CMake, but in my case it seems that Visual Studio is ignoring my setting.
I would like to build google-mock with /MD. This is the default setting in the project.
In a fresh build directory, built with:
cmake -G "Visual Studio 12 2013" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\"1.7.0" -DCMAKE_CXX_FLAGS_RELEASE="/MD /O2 /Ob2 /D NDEBUG" ../googlemock
All my cmake variables seem correct
However, when I go to build, either via the command line (I'm used to linux..) or from Visual Studio, it uses the /MT flag.
My build command (targeting 32 bit):
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
msbuild /m:4 /property:Configuration=%build_type% ALL_BUILD.vcxproj
Output:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\g
test\include /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest /Zi /nologo /W4 /WX /O2 /Ob2 /Oy- /D WIN32 /D _WIND
OWS /D NDEBUG /D WIN32 /D _WINDOWS /D _UNICODE /D UNICODE /D WIN32 /D _WIN32 /D STRICT /D WIN32_LEAN_AND_MEAN /D GTEST_HAS_PT
HREAD=0 /D _HAS_EXCEPTIONS=1 /D "CMAKE_INTDIR=\"Release\"" /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t
/Zc:forScope /GR /Fo"gtest.dir\Release\\" /Fd"gtest.dir\Release\vc120.pdb" /Gd /TP /wd4127 /wd4251 /wd4275 /analyze- /errorRe
port:queue -J "C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest\src\gtest-all.cc"
(note the /MT hiding in there.)
In Visual Studio, I open the solution, choose release type Release, and in any of the targets, say gtest, Properties -> Configuration Properties -> C/C++ -> Code Generation, the Runtime Library is set to /MT, not /MD as set in the Cmake file.
Same thing happens if I try to build google-test (1.7.0)
Do I just not understand how to set these? Or is there a way to force Visual Studio to use the right flag without manually opening Visual Studio and setting it?
The CMake build systems of both google-test and google-mock aren't well behaved. They do not obey the compile options and runtime option set up by the user for good reason and override those with options that they consider reasonable for testing purposes.
To prevent the replacement of MD with MT you can set the option gtest_force_shared_crt to ON in the CMake cache. The modification of other compile options (e.g., warnings) however is done unconditionally.
When two visual studio processes compile in parallel, the second will reuse the instance of mspdbsrv started by the first one. So when the first build is terminated and the whole process tree terminated (e.g. by Jenkins), the other build fails.
That bug report describes how to start it manually so it does not get killed. But the thing is also famous for occasionally forgetting to close files, which can fail the next build.
Is there a combination of options under which mspdbsrv would not be used at all?
Ok, I am looking for a generic answer, so I didn't include the current options at first. But the answer so far sounds like mspdbsrv shouldn't be used when some options are not used. Except in the trivial test project used (by CMake) to check whether MSC++ works they are not used, yet it does start mspdbsrv.exe. The trivial projects is a .vcproj file, compiled via devenv.com CompilerIdC.vcproj /build Debug. The build runs following commands for C:
cl.exe /Od /D "_UNICODE" /D "UNICODE" /FD /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W0 /c /TC ".\CMakeCCompilerId.c"
link.exe /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"Debug\CompilerIdC.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /NODEFAULTLIB:"libc" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\CMakeCCompilerId.obj"
mt.exe /outputresource:".\CompilerIdC.exe;#1" /manifest ".\Debug\CompilerIdC.exe.intermediate.manifest"
and following commands for C++:
cl.exe /Od /D "_UNICODE" /D "UNICODE" /FD /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W0 /c /TP ".\CMakeCXXCompilerId.cpp"
link.exe /OUT:".\CompilerIdCXX.exe" /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"Debug\CompilerIdCXX.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /NODEFAULTLIB:"libc" /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\CMakeCXXCompilerId.obj"
mt.exe /outputresource:".\CompilerIdCXX.exe;#1" /manifest ".\Debug\CompilerIdCXX.exe.intermediate.manifest"
This still starts the mspdbsrv.exe. I actually used the fact that it does to protect it from Jenkins killer for the time being.
The option /FD is injected by devenv.com. I've tried to run it via msbuild, but that invokes vcbuild (Visual Studio 2008) and that executes the same commands including the /FD option. And the WinCE targets are only supported by the Visual Studio generators in CMake, so I can't switch to make easily.
This is not a common complaint, there's no existing feedback report for it on connect.microsoft.com. Otherwise the recommended way to accelerate resolution of problems like this, you do get a Microsoft engineer to look at the issue.
And no, there is no specific option to disable mspdbsrv.exe. There is only one for the opposite, to enable it. The /FS option forces the compiler to use it.
Strong hints that you are using a compiler option that's not commonly used on build machines. You did not document anything so guessing is required. The number one candidate is the /MP option. Which always requires the compiler to use mspdbsrv.exe since it will launch the compiler multiple times, each working on one of the source files that were passed. A scenario where mspdbsrv.exe is required since each compiler instance is likely to want to write to the same .pdb file, particularly the program database specified in the /Fd option.
So look at your build scripts and remove /MP if you see it. Document the options you pass to the compiler next. Filing a feedback report at connect.microsoft.com is strongly recommended.
After update: your build server is using the /FD option incorrectly. The MSDN Library article has this to say about it:
/FD is only used by the development environment, and it should not be used from the command line or a build script.
I cannot predict what effect it has on mspdbsrv.exe, it very likely has one since /FS is strongly linked to /Gm which is strongly linked to /FD. Removing the option is the obvious next step.
I am sure you must already have tried setting "Generate Debug Info" -> No
Not sure if below came to your mind or not:
Try removing (or rename or move to other location) mspdbsrv.exe and related dlls (mspdb80.dll and mspdbcore.dll) and then see what happens.
This is just a wild guess but worth trying.
I use Intel C++ Compiler v. 13 for OS Windows in MS Visual Studio 2010. This compiler support vectorize a code. I want to disable this option, but save enabled -O2 optimization. I set for this goal /Qvec- flag in Project -> Properties -> Configuration Properties -> C/C++ -> Command Line -> Additional Options window (label "Inherit from parent or project defaults" is enabled). In All options section shown these keys:
/Zi /nologo /W3 /Od /Ot /Qipo /Qopt-matmul /D "WIN32" /D "NDEBUG" /D
"_CONSOLE" /D "NOALIAS" /D "_UNICODE" /D "UNICODE" /EHsc /MT /GS /Gy
/fp:fast /QaxAVX /Zc:wchar_t /Zc:forScope /Qopenmp /Qstd=c99
/Qstd=c++11 /Fp"Release\mformat.pch" /Fa"Release\" /Fo"Release\"
/Fd"Release\vc100.pdb" /Qvec-report2 /Gd
But in compilation report output this messages:
service.cpp(164): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(535): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(543): warning : loop was not vectorized: nonstandard loop
is not a vectorization candidate.
etc...
And program time is not change. How i can disable vectorization and no set \Od key?
Found this in the document "A Guide to Vectorization with Intel® C++ Compilers"
To allow comparisons of vectorized with unvectorized code,
vectorization may be disabled with the switch /Qvec- (Windows*) or
-no-vec (Linux* or Mac OS* X).
Lots of additional good information on the Intel® Composer XE Suite page.
I couldn't find anything useful on the MSDN for this case. Using Dependency Walker, in the module list, I see a mixed usage of Console and GUI.
Does this have an impact when compiling a DLL?
This option only has an effect on applications (exe), not on libraries(dll).
Its documentation says:
The /SUBSYSTEM option specifies the environment for the executable.
The choice of subsystem affects the entry point symbol (or entry point
function) that the linker will select.
This does not affect libraries, which have their own (optional) entry point.
Additional information following CyberShadow's comment: The subsystem field itself seems to be ignored when a DLL is loaded. This article about CSRSS says (emphasis mine):
Furthermore, each process is associated with one, certain subsystem;
this property is being set by the linker (during the compilation
process), and resides in the following PE structure field: [...]
My below reply is just some findings.
I tried to create below types of project within VS2015:
Win32 console app project
Win32 DLL project
Win32 Windows app project
Below are their complete linking options:
Win32 console app project
/OUT:"C:\Temp\ConsoleApplication3\Debug\ConsoleApplication3.exe"
/MANIFEST /NXCOMPAT
/PDB:"C:\Temp\ConsoleApplication3\Debug\ConsoleApplication3.pdb"
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X86
/INCREMENTAL
/PGD:"C:\Temp\ConsoleApplication3\Debug\ConsoleApplication3.pgd"
/SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"Debug\ConsoleApplication3.exe.intermediate.manifest"
/ERRORREPORT:PROMPT /NOLOGO /TLBID:1
Win32 DLL project
/OUT:"C:\Temp\ConsoleApplication3\Debug\Win32DLLProject1.dll"
/MANIFEST /NXCOMPAT
/PDB:"C:\Temp\ConsoleApplication3\Debug\Win32DLLProject1.pdb"
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "odbc32.lib" "odbccp32.lib"
/IMPLIB:"C:\Temp\ConsoleApplication3\Debug\Win32DLLProject1.lib"
/DEBUG /DLL /MACHINE:X86 /INCREMENTAL
/PGD:"C:\Temp\ConsoleApplication3\Debug\Win32DLLProject1.pgd"
/SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"Debug\Win32DLLProject1.dll.intermediate.manifest"
/ERRORREPORT:PROMPT /NOLOGO /TLBID:1
Win32 Windows app project
/OUT:"C:\Temp\ConsoleApplication3\Debug\Win32WindowsProject1.exe"
/MANIFEST /NXCOMPAT
/PDB:"C:\Temp\ConsoleApplication3\Debug\Win32WindowsProject1.pdb"
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X86
/INCREMENTAL
/PGD:"C:\Temp\ConsoleApplication3\Debug\Win32WindowsProject1.pgd"
/SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"Debug\Win32WindowsProject1.exe.intermediate.manifest"
/ERRORREPORT:PROMPT /NOLOGO /TLBID:1
So we can see, for a /DLL, /SUBSYSTEM:WINDOWS is defined.
Then I tried to build a DLL with 3 different SUBSYSTEM values:
CONSOLE
WINDOWS
NOT SET
There are other values as well, but I can only build successfully with the above 3. Other values will lead to linking errors, which means some external symbols are needed.
The full list of possible SUBSYSTEM values is:
You can use the CFF Explorer to inspect the PE/COFF binaries.
The SUBSYSTEM header field locates at the file offset 0x14C of a PE/COFF file. It is part of the Optional Header.
/DLL /SUBSYESTEM:CONSOLE
/DLL /SUBSYESTEM:WINDOWS
/DLL and no /SUBSYESTEM option (by selecting NOT SET in VS2015 project properties page
Interestingly, the NOT SET and WINDOWS values lead to the same content in the binary header.
And I compared the whole binary of the 3 DLLs. It seems the rest of the binaries are all the same, except for some timestamp and debug info.
This is just some fact I found. How /SUBSYSTEM option affects the binary behavior depends on how the loader interprets this field.
In one of the projects I participated in, the /SUBSYSTEM:CONSOLE and /DLL are used together, which is different from the default combination for a DLL project. But it seems nothing bad happens. So I agree with #Frédéric Hamidi that this flag has no functional impact to a DLL.
During our application startup, we are making a call to ::LookupAccountSid(). When I build targeting the x86 architecture, this call is nearly instantaneous. However, when I target x64 (debug or release), the call generally takes over 40s to complete. Since this is occurring during application startup, the result is fairly unpleasant as it will appear to the user that the application is not launching.
I am running Windows 7 Professional 64-bit on a Dell Studio XPS 16 (Intel Core i7 Q 720).
Our application is a native Windows application written in C++.
My compiler options (CCOPTS) and linker options (LINKOPTS) are as follows:
CCOPTS = "/nologo /Gz /W3 /EHs /c
/DWIN32 /D_MBCS /Ob1 /vmg /vmv /Zi /MD
/DNDEBUG /DDV_BUILD_DLL /DIV_BUILD_DLL
/DDVASSERT_EXCEPTION /Zc:wchar_t-"
LINKOPTS = "/manifest:no /nologo
/machine:X64 kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib /DEBUG
/subsystem:windows /DLL"
Any help would be greatly appreciated :D
These kind of long delays are almost always network related. This blog post shows a troubleshooting strategy.