How to manage the analysis overhead of Correctness Modeling in Intel® Parallel Advisor 2011

Using Intel® Parallel Advisor 2011 to model the correctness of an annotated program is a very thorough and detailed process, and due to this, it adds significant overhead to the run time of the application. This overhead is caused by several factors. Some of the reasons correctness modeling runs slowly are:

1. Correctness analysis must examine every instruction at runtime and additional executable code is added where necessary to monitor specific portions of the application
2. The tool monitors every memory access and maintains additional context related to the memory accesses
3. Users are asked to use a non-optimized (debug) version of the application
4. Requiring symbol information may slow down the application in some instances
5. Annotations add additional time to the code

Certain code and annotation characteristics can cause this overhead to increase dramatically. Some of these characteristics include:

1. Heavy use of several different "lock" annotations
2. Memory intensive operations inside annotated sites or tasks

There are several options for reducing the time it takes to collect correctness data; however they may also decrease the usefulness of that data. Listed here are some suggestions with some of the possible consequences.

1. Decrease the workload of the application – This is the recommended way to reduce Correctness overhead. Try to choose an input data set or input parameters that execute the most code paths, with as little repetition as possible.
2. Reduce the number of annotations – Running separate collections for each site while commenting out other sites will break up the process into several shorter collections instead of one long collection.
3. Only use lock zero, e.g. ANNOTATE_LOCK_ACQUIRE(0), for lock annotations unless you are trying to specifically model the behavior of fine-grain locks.
4. Use the /Zi flag for symbol information instead of /ZI - This can speed up the runtime of the debug application but you will not have the option to "Edit and continue" while debugging.
5. Allow some optimizations in the build – For example, use the "O1" or "O2" flags. These flags may make it difficult for Advisor to detect some Correctness issues and to present accurate source code location information in the Correctness results. Explicitly turning off in-lining while leaving these optimizations on may improve the quality of this information.
6. Compile annotated code with optimizations turned off, but allow optimizations on non-annotated code – This may complicate the build process but it can reduce the overhead from non-optimized code outside of the annotations.

Note that number 1 is the recommended solution to reducing correctness modeling overhead. The other options are only suggestions that may or may not work for your application. They may also reduce the quality or accuracy of the results. You should always try to reduce the size of your data set before trying the other options and, as always, your mileage may vary.

23 May, 2011


--
Source: http://software.intel.com/en-us/articles/how-to-manage-the-analysis-overhead-of-correctness-modeling-in-intel-parallel-advisor-2011/