The
Intel®
Advisor
Dependencies tool
runs your target
application and watches its memory access operations to predict possible data
sharing problems.
Running the Dependencies Analysis
You can run the Dependencies tool to collect predicted parallel dependencies data:
In Intel® Advisor :
-
In the Advisor Workflow tab next to the Check Dependencies group box find the
button.
-
File > New > Start Dependencies Analysis.
-
Or using the
icon in
the toolbar.
Via Intel® Advisor CLI:
$ advixe-cl -collect=dependencies [-action-option] [-global-option] [--] <target> [<target options>]
Refer to section Viewing Data from the Dependencies Tool for details on getting and understanding the Dependencies analysis results.
Why Do I Need the Dependencies Data when Adding Vectorization?
Use the Dependencies tool in case the Compiler cannot vectorize your code automatically. In most cases you receive the Compiler diagnostic, explaining the Compiler's conservative decision to keep the code scalar. Assuming you are currently in the Vectorization Workflow, and have already collected the Survey data, refer to the Survey Report tab in the Intel® Advisor GUI. You can select the loop that you are investigating right now and review the Vector Issues column of the Survey report, which provides information about possible issues that might predict vectorization. Click the links in the column to see the Compiler Diagnostic Details. If the Compiler assumes that the loop has dependency, you can check it with the Dependencies tool. And finally, if the Dependency is not confirmed, you can force the Compiler to vectorize the loop via adding corresponding #pragma.
For detailed description of the issue with code examples applicable to your specific case, refer to the Recommendations tab in the Survey Report and/or Refinement Report.
Why Do I Need the Dependencies Data when Adding Threading Parallelism?
Use the Dependencies tool before you have modified your serial program to use parallel execution. By observing the data accesses and the annotations during execution, it knows which tasks the accesses are in. The data collected and analyzed appears in the Dependencies Report window. You can find bugs before they happen - you do not have to wait for your parallel program to fail and then debug it. As you fix the detected problems, rebuild your application and run the Dependencies tool again. When the Dependencies tool does not detect any Problems, a No Problems Detected message appears instead of the Dependencies Report.
When you write a serial program, you know the order in which its operations will execute. When you create two tasks within that program and execute them in parallel, any operation in either task can execute before, after, or simultaneously with any operation in the other task (or an instance of the same task). Errors occur when two tasks that are executing simultaneously contain operations that access the same memory location. If one of them writes to the location and the other one reads from it, then the result of the read depends on whether it happens before or after the write. If they both write to the location, then the final value in the location depends on which write happens last.
These errors are called data sharing problems. They are also sometimes referred to as conflicts, or data races, because the behavior of the program depends on which operation gets to the data first, or as data dependencies, because the result of executing a data access operation depends on other operations that have previously accessed the same data.
A correct parallel program is expected to be reliable, and typically deterministic in the output it produces. The problem with parallel data sharing problems is that they are non-deterministic. This rearrangement of the order of operations can easily change the behavior of the program. Since the order of operations may be different every time the program is executed, the resulting errors can be hard to reproduce, and even harder to debug. A program may execute perfectly 100 times; then, the next time, one task runs a little bit faster, and reads from an object on the heap before it has been written by another task. Or when you add some print statements or use the debugger, the task slows down and the bug disappears.
After you change annotations or fix data sharing problems, run the Dependencies tool again to check the modified program. In addition to data sharing problems, the Dependencies tool can predict other problems, such as mismatched annotations pairs and lock-related warnings such as a deadlock. Run this tool until the predicted problems have been fixed. After you fix the data sharing problems, run the Suitability tool again to check your program's predicted performance characteristics.
Caution
To catch the most data sharing problems, run the Dependencies tool on your annotated serial program and the Intel® Inspector on your parallel program. As it examines your annotated serial program, the Dependencies tool might not detect all possible sharing problems for a given workload, so you can try changing the workload for better results. Also, the tool cannot find dependencies for the already vectorized loops. After you have modified your program to run in parallel, use Intel® Inspector to check for problems. Because Intel® Inspector observes the program running in parallel, it can detect some sharing problems that the Dependencies tool will not detect. For information on kinds of sharing problems that Intel Advisor will not report, see the help topic Dependencies Tool Limitations.