I am working with mixed Native and Managed Visual C++, using STL in the Native. I have a strange problem. It seems that when I compile my software in Release mode with all the optimizations set, my software consistently runs slower than in Debug mode. What could be wrong here?
These are my Debug command line options:
/Od /D "WIN32" /D "_DEBUG" /D "_UNICODE" /D "UNICODE" /FD /EHa /MDd /Fo"Debug\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /Zi /clr /TP /errorReport:prompt /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll"
These are my Release command line options:
/Oi /Ot /Oy /GT /GL /D "WIN32" /D "_SECURE_SCL=0" /D "_HAS_ITERATOR_DEBUGGING=0" /D "VC_EXTRALEAN" /D "_UNICODE" /D "UNICODE" /FD /EHa /MD /Fo"Release\" /Fd"Release\vc90.pdb" /W3 /nologo /c /clr /TP /errorReport:prompt /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll" /FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll"
That's utterly impossible to diagnose from the command line switches, you have to use a profiler.
One thing that's relevant however is you using the /clr option. Unless you explicitly use #pragma managed in your code, everything will be translated to IL, even the STL template code. Which means that your optimization settings have no effect whatsoever since they only apply to generated machine code. You are then subject to what the JIT compiler does for optimization. It will not optimize by default when you have a debugger attached for example.
Try profiling the release version to see if you notice any obviously incorrect slowness. If needed, compare it to a profile output from the debug version.
Alternately if the debug version is subjectively "fast enough", just release that (although there might be reverse-engineering implications).
Related
Consider code:
#include <stdio.h>
int main() {
int a = 4;
#if 1
printf("Hello world\n");
#endif a++;
printf("a is %d\n", a);
}
Inadvertently, statement a++; is on the same line as a #endif and is not evaluated. As a result, the final output is:
Hello world
a is 4
On x86-64 clang 12, this is captured as a warning with using option -Wextra-tokens. See here.
I tried compiling this on Visual Studio 2019 MSVC, with command line options:
/JMC /permissive- /ifcOutput "Debug\" /GS /analyze- /W3 /Zc:wchar_t /I"../include/" /ZI /Gm- /Od /sdl /Fd"Debug\vc142.pdb" /Zc:inline /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /FC /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\windows.pch" /diagnostics:column
There is no warning of any sort on compilation. Is there a setting that can be passed to the compiler in MSVC that detects extra tokens?
Edited to add:
As answered by user Nathan Pierson, it was indeed option /Za that worked. It does not seem to be on by default. I was also unable to use the Visual Studio Project Properties dialog to find out the option to set. Yet, one can feed in extra options manually thus:
There's compiler warning C4067. It looks like you need to set the flag /Za for it to apply to #endif directives.
In the Visual Studio properties page, this flag is controlled by the setting "Disable Language Extensions" in the Language subsection of the C/C++ section.
To accurately profile an application, under linux, it is recommended to have optimizations on and debug symbols on via compile options -O2 -g for gcc or g++. This enables profiling to include the user's C++ code and not point to assembly code instead as possible hotspots, for instance. See for instance, here.
In Visual Studio IDE, for usage of profilers, what are the equivalent compile/linking options?
In Release mode of Visual Studio, under "Whole Program Optimization" property sheet that comes loaded by default, the Debug Information Format gets set to Program Database with command line option /Zi. See image:
Is this the Visual Studio/Windows/MSVC (Cl.exe, MSBuild.exe) equivalent of -O2 -g? Or are there any other equivalent settings?
ETA: Under the default Visual Studio 2019 release mode settings, the following flags are set:
/permissive- /ifcOutput "x64\Release\" /GS /GL /W3 /Gy /Zc:wchar_t /I"E:\local\boost_1_72_0" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc142.pdb" /Zc:inline /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /FC /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /FA /Fp"x64\Release\windows.pch" /diagnostics:column
Have a look at the project properties, under C++ optimization. The IDE tells you everything.
I downloaded the source code for a library that resembles the processing library but for c++ called libxd. I used CMake to generate project files for Visual Studio 2019 which worked successfully. When trying to compile the solution for all of the provided build modes, I get the following errors:
The first error invlaid numeric argument '/Wno-narrowing' is what I'm concerned about for now. I'm trying to figure out why this argument is being provided to the compiler. When looking in the properties window for the xd project in the solution I can see the command line arguments that are supposed to be provided to the compiler in the C/C++ > Command Line tab. I verified that there is no /Wno-narrowing option provided. When looking at the build output it can be seen that the option -Wno-narrowing is being provided to the compiler. Can someone help me figure out why this argument is being passed? I looked throughout the compiler properties window to see if I could see anything that would be affecting it but I can't see anything that would affect this.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe /c /IC:\dev\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
Tracking command:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\dev\libxd\build\xd.dir\Debug\xd.tlog /r C:\DEV\LIBXD\SRC\OPENSANS.CPP /b MSBuildConsole_CancelEventfa83e1bb599743cfa0c02eb67d579e28 /c "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe" /c /IC:\dev\Users\olive\Downloads\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
cl : command line error D8021: invalid numeric argument '/Wno-narrowing'
The command exited with code 2.
The error is caused because that's not a valid MSVC flag. The flag is there because the CMakeLists.txt file demands it:
set_source_files_properties(src/opensans.cpp PROPERTIES COMPILE_FLAGS -Wno-narrowing)
That project specifies what it supports for building under Windows and it's not MSVC.
Windows Prerequisites: mingw-w64 version >= 4.8.1
So you either need to build it in the supported way, or modify the build scripts to allow for MSVC.
That would entail figuring out what the flag does in gcc (disables diagnostic messages about narrowing issues) and finding the equivalent in MSVC, probably a /disable:nnnn variant, once you figure out the nnnn. Figuring that out should be relatively painless since MSVC will tell you that when you compile it - lots of Cnnnn - something to do with narrowing warning messages.
Or you could just disable the line that adds the flag (for MSVC builds only) and see if it still builds. Of course, in the spirit of open source, you should then notify the author what it took to get it going, they may be happy to support MSVC if the effort is not too high.
I'm trying to build my dll file as x64, here are the configurations I have done on VisualStudio:
I have set solution and project platform to x64:
According to this answer, I have changed naming convention from __cdecl to __fastcall:
According to this comment I have added the argument _WIN64 to Preprocessor Definitions:
But still, when I rebuild my project and open my dll file using notepad, I see PE L which means my dll file is 32 bit.
Here's the command line options of the C/C++ settings (for better reading, I put a couple of line breaks in there):
/JMC /permissive- /GS /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl
/Fd"x64\Debug\vc142.pdb" /Zc:inline /fp:precise /D "_WIN64" /D "_DEBUG" /D
"_CONSOLE" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX-
/Zc:forScope /RTC1 /Gr /MDd /FC /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\"
/Fp"x64\Debug\DllCall-CppConsoleApp-1.pch" /diagnostics:column
Linker settings:
What should I do?
I need to compile a program automatically with different platform toolsets. The compilation is done using cl.exe and link.exe like so:
cl.exe file.c /GS- /PlatformToolset=vc140xp /analyze- /W3 /Gy /Zc:wchar_t /Gm- /Od /Zc:inline /fp:precise /D \"WIN32\" /D \"_WINDOWS\" /D \"_UNICODE\" /D \"UNICODE\" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MD /Fa\"\" /EHsc /nologo /Fo\"\" /Fp\"\" /diagnostics:classic /link %link_additional% /ENTRY:wWinMain /SUBSYSTEM:WINDOWS /MANIFEST:EMBED /NXCOMPAT /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:NONE /MACHINE:%arch% /OPT:REF /SAFESEH /INCREMENTAL:NO /SUBSYSTEM:WINDOWS /MANIFESTUAC:\"level = 'asInvoker' uiAccess = 'false'\" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1\
I'm using the switch /PlatformToolset=vc140xp but, the cl.exe doesn't seem to reconginze it, i get an error:
Unknown Option: /PlatformToolset
Is there a way you can change toolset using cl.exe, without msbuild and vcproj ?
Just incase someone need it, i was able to solve this isuue. i added this option to cl.exe:
/D \"_USING_V110_SDK71_\"
And also i modified this option:
/SUBSYSTEM:WINDOWS
to
/SUBSYSTEM:WINDOWS,5.01
After the application runs succesfully on windows xp. You might encounter some problems if you are heavily useing crt in your exe, in my exe i only needed CRT to define Tls callbacks, they do not work without CRT, so i guess maybe this is why this worked for me