Visual Studio Profile Guided Optimization

user_619493 0
Viewed 2069

I have a native C++ application which performs heavy calculations and consumes a lot of memory. My goal is to optimize it, mainly reduce its run time.
After several cycles of profiling-optimizing, I tried the Profile Guided Optimization which I never tried before.

I followed the steps described on MSDN Profile-Guided Optimizations, changing the compilation (/GL) and linking (/LTCG) flags. After adding /GENPROFILE, I ran the application to create .pgc and .pdg files, then changed the linker options to /USEPROFILE and watched additional linker messages that reported that the profiling data was used:

3>  0 of 0 ( 0.0%) original invalid call sites were matched.
3>  0 new call sites were added.
3>  116 of 27096 (  0.43%) profiled functions will be compiled for speed, and the rest of the functions will be compiled for size
3>  63583 of 345025 inline instances were from dead/cold paths
3>  27096 of 27096 functions (100.0%) were optimized using profile data
3>  608324578581 of 608324578581 instructions (100.0%) were optimized using profile data
3>  Finished generating code

Everything looked promising, until I measured the program's performance.

The results were absolutely counterintuitive for me

  • Performance went down instead of up! 4% to 5% slower than without using Profile Guided Optimization (when comparing with/without the /USEPROFILE option).

  • Even when running the exact same scenario that was used with /GENPROFILE to create the Profile Guided Optimization data files, it ran 4% slower.

What is going on?

compiler-optimization visual-studio-2015 visual-studio profiling c++
2 Answers

Looking at the sparse doc here the profiler doesn't seem to include any memory optimizations.

If your program takes 2GiB of memory, I'd speculate that the execution speed is limited by memory access and not by the CPU itself. (You also stated something about maps being used, these are also memory limited) Memory access is difficult to optimize for a profiler, cause it can't change your malloc calls to (for example) put frequently used data into the same pages or make sure they are moved to the same cache line of the CPU.

In addition to that the profiler may introduce additional memory accesses when trying to optimize the bare CPU performance of your program. The doc states "virtual call speculation", I would speculate that this (and maybe other features like inlining) could introduce additional memory traffic, thus degrading the overall performance cause memory bandwidth is already the limiting factor.

user_44741200
Related