I need to profile an application compiled with intel's compiler via VC++.
I'm using VTune to profile my code.
My understanding is that in release mode I won't have the debug information
that is necessary for the profiler to profile my code while in debug mode, the result
of the profiling will not be pertinent.
What should I do ? Is it possible to add debug info in release mode?
How can I set this mode?
If so, will I still benefit from all the optimization (inlining etc.)?
You should certainly profile with optimisations enabled (compiler option /O3). /Zi is the Intel compiler switch (on Windows) to enabled debugging information.
Because of the optimisations, some functions may be missing from the debugging information due to inlining, but VTune will cope with that.
You can generate program database files (PDB) even in release target. Go to project properties, Linker/Debugging and check the option "Generate Program Database File". It is usually something like "$(TargetDir)$(TargetName).pdb". Now, it depends whether VTune knows how to interpret PDB files...
Function inlining and interprocess optimizations will make your profile hard to interpret. That is why it is a good idea to profile in both debug and release modes. If release mode only shows function foo using 80% of the program time, you can use the debug profile to see that function bar, which was inlined into foo, is using 60% of foo's time.
Related
If debug information is stored in a program database (not as part of an executable), is there any reason not to always build with it (e.g., MSVC's /Zi)?
In CMake, the default configurations are, "Release", "Debug", "RelWithDebInfo", and "MinSizeRel". Is there a reason not to only use "Debug" and "RelWithDebInfo" (perhaps renamed to "Release")?
Does it have any impacts on the size or performance of the code? Is the answer different for gcc or clang than it is for Visual C++?
Update
I did come across these posts that are similar:
Anything wrong with releasing software in debug mode?
Debug vs. RelWithDebInfo
However, neither of these get to the question of Release vs. RelWithDebInfo.
Yes. I could do a test on an executable with Release vs. RelWithDebInfo. That would definitely give me the answer about the size of the code, but would be very difficult to conclude that it has NO impact on performance if my test case showed similar performance. How would I know if I exercised aspects of the language that might be impacted by the change? That is, empirical testing could produce a false negative.
Releasing with debug info is mandatory for real-life development. When shit happens your primary tool would be a crash dump analysis that would be rather pointless without debug information. Note that this does not imply shipping debug info with product.
As for "little differences" between vc++ and gcc I would like to mention that by default vc++ emits debug information in a separate file while gcc will squeeze it into executable. It is possible to separate debug information on gcc as well, however doing so is not as convenient and requires some extra steps.
If you build as Release, surely you won't have Debug Info in the binary. I could see a lot of cases on Windows that people build "Release", but add flags to have debug info. So, i think the default real-life case for most Windows Users, even without knowing that, is Release With Debug Info.
With CMake, you have all three options and one more.
Release means no debugging symbols at all, and MAY also means build with optimizations.
RelWithDebugInfo means build with debug symbols, with or without optimizations. Anyway, the debug symbols can be stripped later, both using strip and/or obj-copy. If you use strip, the output can be saved. I guess the format is DWARF, version 4 or 5.
So, RelWithDebugInfo gives you Release mode binaries, and symbols can be stripped and kept apart. In some projects i have worked, that was the ONLY configuration used.
We must not forget about ASSERTS, at least for C/C++. Building with DEBUG, all Asserts are enabled, so they are not removed from the code during preprocessing. Release and RelwithDebugInfo remove the Asserts, so you won't have them. Some projects nowadays prefer to keep Asserts while developing (so that tests can catch "software" errors during development), and then finally remove in Production Code. Some other projects, for whom Fault-Tolerance is a must, may want to keep Asserts even in production code, so that software cannot execute with wrong Assertions about the software itself.
So,
RelWithDebugInfo: Optimized Build, With Symbols to be stripped, no Asserts
Debug: Not optimized, With Symbols that CAN be stripped, With Asserts.
Release: Optimized, No Symbols, No Asserts.
Recently we have cases on Release vs RelWithDebInfo, we compile a shared lib, and found either the performance and the lib file size has a significant difference, Release is much more runtime faster and less file size.
So it looks like Release should be used when shipping on production.
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.
When I try to build the source with debug mode the stack shown is totally diffrent and in case of release there are only a few methods shown in the backtrace with gdb ,
Why does this happen ? Is this because in debug mode there are extra methods , How can have two methods have the same address in debug and release mode .
Also in that case How can I build to to have accurate address information with complete stack trace . Any help would be appreciated since I am new to debugging on Linux , Windows it was much easier it seems with pdb files .
As discussed in the comments to #rockoder's answer, besides lacking debug symbols (which would be included with -g) in an optimized build whole function calls may not be present any more due to inlining.
When I try to build the source with debug mode the stack shown is
totally diffrent and in case of release there are only a few methods
shown in the backtrace with gdb , Why does this happen ? Is this
because in debug mode there are extra methods?
It is probably just due to compiler optimizations. What you call release build is probably built with compiler speed optimizations enabled and debug symbols disabled. Speed optimizations include code inlining which just copies function code in place instead of calling it, so function is not visible in call stack.
There could also be some extra/different methods, if the code was written with some appropriate preprocessor checks.
How can have two methods have the same address in debug and release
mode .
Depends on what your debug and release mode are. If they use same compiler optimizations and differ only in debug information, methods will have same addresses. If you debug build is not optimized (-O0 on GCC) then methods will be larger, as much unnecessary work is done, for example variables are read from memory before every manipulation and written back after it. Since each method will probably be smaller, functions will have different addresses, as they are generally packed one after another.
Also in that case How can I build to to have accurate address
information with complete stack trace .
Enable debug information. On GCC that would be -g3 (or -g or similar). This adds enough information for code address <-> source line queries (either from debugger or crash stack dump).
Any help would be appreciated since I am new to debugging on Linux ,
Windows it was much easier it seems with pdb files .
Are there any significant differences with Windows binaries debugging?
g++/gcc has many options used for debugging a program but the most common one is -g. Refer link. The first option discussed is -g.
Some additional information here.
Example:
Compile code without -g:
g++ broken.cpp -o broken_release
Compile code with -g:
g++ -g broken.cpp -o broken_debug
Now fire ls -l and note the size different between the files broken_release and broken_debug. Size of broken_debug should be greater then that of broken_release. That's because it contains debug information which could be used by debuggers like gdb.
The game engine I am working with is too slow in the debug build and is impossible to debug the game. One of the things I would like is for the compiler to inline small functions (especially in Vector/Matrix and container classes). This may or may not speed up the game in debug build. Before profiling heavily and trying to figure out bottlenecks I thought I would try this first as I would have to do minimal work and the results may be promising.
So, is there a way to get the Visual C++ compiler to inline functions in debug builds?
Project options -> C/C++ -> Optimization -> Inline Function Expansion. Turn this to /Ob2. Do this in your Debug configuration.
In Release, inline function expansion is implied by other optimization settings, so even though by default all configurations say "Default" for the setting, the behavior is indeed different.
I believe Debug builds should have inline expansion behavior the same as release; there's really no reason not to.
http://msdn.microsoft.com/en-us/library/47238hez.aspx
You're confusing two compiler options. /O influences optimization, including inlining. /ZI creates the PDB file for debugging. They can be set independently.
It may be useful to clone the "Debug" configuration, though, and create a "Debug-optimized" configuration with both /O1 and /ZI.
You might try __forceinline. Be sure to read about debug builds on that page (turn off the /Ob0 option).
My suspicion is that this will not change the performance very much. Another thing to try if you haven't already is just to add symbols to a release build. It works fairly well for debugging a lot of issues.
DEBUG is defined by Visual Studio when a project is compiled in Debug mode so:
#ifdef DEBUG
inline void fn() {
#else
void fn() {
#endif
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.