I have built an open-source application from the source code. Unfortunately, the original executable runs significantly faster. I tried to enable few compiler optimizations, but the result wasn't satisfactory enough. What else do I need to make in Visual Studio 2008 to increase the executable performance?
Thanks!
Basically try enabling everything under Optimisation in project settings, then ensure Link Time Code Generation is on, enable Function-level linking and full COMDAT folding (that only reduces the size of the EXE but could help with caching), and turn off security features such as by defining _SECURE_SCL=0. Remember some of these settings have other implications, especially the security ones.
Define _SECURE_SCL=0.
http://msdn.microsoft.com/en-us/library/aa985896(VS.80).aspx
Try to enable SSE instructions, when compiling. Also - you can try to compile using different compiler (GNU GCC).
+There might be enabled some debug defines, shich also can reduce speed.
+Check, that original .exe has same version as one you are trying to compile.
The open-source precompiled binary is most likely (whit out know which project you are working with) compiled with GNU GCC (Mingw on Windows). That might be the reason that it is faster. According to question: performance g++ vs. VC++ some things are considerably slower if you use VC++.
Related
Since C++ uses headers for now, sometimes one header includes another and you fail to notice it, as a result of that the code may compile with one compiler and not with the other, or maybe one feature is implemented in one compiler but not the other, so, I was wondering if there's a way to have visual studio check if the project will compile with both VS compiler and g++ somehow? Or do I just have to manually recompile with both compilers every time? If I have to recompile with both compilers, how can I automate that process with visual studio so I don't have to do it manually?
The development cycle of gcc is faster than that of MS Visual Studio. So asking Visual Studio "will my code be compiled correctly by g++?" is meaningless - it will never know which features and bugfixes the latest version of gcc has.
Also, there is no point in asking such a question at all - if you want to know "what will happen if I do X", just do X!
What you really want to know, I guess, is something like "Are my #include directives compatible with C++ Standard?". MS Visual Studio is just an implementation - it's not a portability-checking tool. It does its best to compile the code, and do it correctly, which is a great task by itself (with c++ being so hard to compile).
gcc is yet another implementation of c++, with its own headers. Actually, from my experience, the mingw c++ headers are more "minimalistic", that is, they try to not include one-another when possible. My guess is, they try to minimize compilation time for systems that don't use precompiled headers, while MS Visual Studio regards precompiled headers as an essential feature.
So better use gcc/mingw as your "standard compliance" check.
VS2015 supports the clang compiler, which is generally the most compliant compiler of the three. You could compile your code with clang.
It's important to distinguish that a compiler and standard library implementation are not the same thing. i.e. you can mix and match compilers with the standard libraries that ship with different toolchains. So compiling with clang will not pick up issues with variance in standard library implementations.
To do that you would have to link against and supply the headers for the standard library implementation you would like to link against. Visual Studio, by default links against it's own runtime and includes msvc runtime headers, you would have to change your project configuration to achieve it but it should be possible. It would be a lot less hassle to simply compile it with the target platforms own toolchain, however.
I am recently working with Eigen library with visual C++ to solve a very large sparse linear system. Program works really fast in Release mode, but in Debug mode it takes hours to solve. I traced the timing, the program takes long time in "solve" function of Eigen. I want to build the project in debug mode as I need to debug a lot. Now is there a way not to generate debug information for Eigen portion? Or is there any other workaround for this problem?
#MichaelWalz's answer is great, but I would like to add (as I have outlined in my comment to your question) that I strongly recommend not using Eigen in Debug mode.
Eigen is a highly efficient, yet very usable matrix library. It achieves its efficiency through a lot of “template magic”, using many layers of abstraction, and relies on the compiler's optimization stages to produce highly efficient code.
Debug mode usually implies that the compiler creates debug symbols, but also disables optimization. In GCC/clang, it is usually equivalent to -O0 -g; I believe in Visual Studio it corresponds to /O0 /DEBUG.
I recommend building all code that uses Eigen in a “release-with-debug-info” mode instead (what CMake calls CMAKE_BUILD_TYPE=RelWithDebInfo). This means that you allow the compiler to optimize, while still generating debug symbols. In GCC/clang, this is usually equivalent to -O2 -g; I believe in Visual Studio it corresponds to /O2 /DEBUG. Personally I have had very good experiences like this; IMHO it is only in very rare circumstances that you actually need to disable optimization completely.
You can disable debug information and enable code optimisation per file.
In the Solution Explorer right click on the file that contains the Eigen function, then chose Properties.
In the dialog that appears, choose the C/C++->Optimisation and chose the same options you have in Release mode.
Then choose C/C++->General and under "Debug Information Format" choose "None". But the presence of debug information has probably no influence on execution speed.
Now almost an every user have a 2 or 4 cores on desktop (and on high number of notebooks). Power users have 6-12 cores with amd or i7.
Which x86/x86_64 C/C++ compilers can use several threads to do the compilation?
There is already a 'make -j N'-like solutions, but sometimes (for -fwhole-program or -ipo) there is the last big and slow step, which started sequentially.
Does any of these can: GCC, Intel C++ Compiler, Borland C++ compiler, Open64, LLVM/GCC, LLVM/Clang, Sun compiler, MSVC, OpenWatcom, Pathscale, PGI, TenDRA, Digital Mars ?
Is there some higher limit of thread number for compilers, which are multithreaded?
Thanks!
Gcc has -flto=n or -flto=jobserver to make the linking step (which with LTO does optimization and code generation) parallel. According to the documentation, these have been available since version 4.6, although I am not sure how good it was in those early versions.
Some build systems can compile independent modules in parallel, but the compilers themselves are still single-threaded. I'm not sure there is anything to gain by making the compiler multi-threaded. The most time-consuming compilation phase is processing all the #include dependencies and they have to be processed sequentially because of potential dependencies between the various headers. The other compilation phases are heavily dependent on the output of previous phases so there's little benefit to be gained from parallelism there.
Newer Visual Studio versions can compile distinct translation units in parallel. It helps if your project uses many implementation files (such as .c, .cc, .cpp).
MSDN Page
It is not really possible to multi-process the link stage. There amy be some degree of multi-threading possible but it is unlikely to give much of a performance boost. As such many build systems will simply fire off a seperate process for seperate files. Once they are all compiled then it will, as you note, perform a long single threaded link. Alas, as I say, there is precious little you can do about this :(
Multithreaded compilation is not really useful as build systems (Make, Ninja) will start multiple compilation units at once.
And as Ferrucio stated, concurrent compilation is really difficult to implement.
Multithreaded linking can though be useful (concurrent .o/.a reading and symbol resolution.) as this will most likely be the last build step.
Gnu Gold linker can be multithreaded, with the LLVM ThinLTO implementation:
https://clang.llvm.org/docs/ThinLTO.html
Go 1.9 compiler claims to have:
Parallel Compilation
The Go compiler now supports compiling a package's functions in parallel, taking advantage of multiple cores. This is in addition to the go command's existing support for parallel compilation of separate packages.
but of course, it compiles Go, not C++
I can't name any C++ compiler doing likewise, even in October 2017. But I guess that the multi-threaded Go compiler shows that multi-threaded C or C++ compilers are (in principle) possible. But they are few of them, and making new ones is a huge work, and you'll practically need to start such an effort from scratch.
For Visual C++, I am not aware whether it does any parallel compilation (I don't think so). For versions later than Visual Studio 2005 (i.e. Visual C++ 8), the projects within a solution are built in parallel as far as is allowed by the solution dependency graph.
today i found out that the compiled static library i'm working on is much larger in Release mode than in Debug. I found it very surprising, since most of the time the exact opposite happens (as far as i can tell).
The size in debug mode is slightly over 3 MB (its a fairly large project), but in release it goes up to 6,5 MB. Can someone tell me what could be the reason for this? I'm using the usual Visual Studio (2008) settings for a static library project, changed almost nothing in the build configuration settings. In release, i'm using /O2 and "Favor size or speed" is set to "Neither". Could the /O2 ("Maximize speed") cause the final .lib to be so much larger than the debug version with all the debugging info in it?
EDIT:
Additional info:
Debug:
- whole program optimization: No
- enable function level linking: No
Release:
- whole program optimization: Enable link-time code generation
- enable function level linking: Yes
The difference is specifically because of link-time code generation. Read the chapter Link-Time Code Generation in Compilers - What Every Programmer Should Know About Compiler Optimizations on MSDN - it basically says that with LTCG turned on the compiler produces much more data that is packed into the static library so that the linker can use that extra data for generating better machine code while actually linking the executable file.
Since you have LTCG off in Debug configuration the produced library is noticeably smaller since it doesn't have that extra data.
PS:
Original Link (not working at 11/09/2015)
The optimization could be the issue here, notably automatically created inline functions will be bigger but faster in release than debug.
Personally I've never seen a release PDB be larger than a debug PDB. Same deal for LIBs.
We find a slight difference in how bcc32 and bcc32ide behave on a
file.
bcc32ide works and bcc32 crashes.
Would there be any detrimental side effects to switching to bcc32ide for our automated builds?
Also, what is the difference between these two compilers (other than one crashes and one doesn't)?
See Re: BCB 6 Compiler slowness and how to speed it up dramatically for an explanation.
Quote:
bcc32ide.exe is a bcc32.exe, but it uses the IDE compiler. For
example, some compiler assertions do not raise with the IDE compiler, but
with bcc32.exe. So replacing bcc32.exe in makefiles by bcc32ide.exe will
allow to compile projects that compile within the IDE, but not at console.
bcc32ide.exe also adds some additional parameters:
-automake Compile only modified files
-verbose Output current compiled line number during compilation
-pch=filename_pch.h Use advanced precompiled headers
-FIfilename Force include (multiple, usage like -Iincludedir)
And it supports multi-process shared access to the advanced PCH file
(required for mtbcc32.exe).