|
|||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
VProf (The Visual Profiler) at NCSA |
|||||||||||||||||||||||||||||||||||||||
|
User Information Home
 NCSA's Help Desk is available 24 hours a day, seven days a week, 365 days a year:
The VProf visual profiler from Sandia National Laboratories is available on the NCSA Xeon cluster (Tungsten), TeraGrid Itanium 2 cluster (Mercury), and SGI Altix (Cobalt). VProf was developed by Curtis Janssen. The VProf Home Page provides more information and a brief user guide. In many cases, you'll need to make no source code changes to use VProf. You'll only need to recompile and relink your application. The recompilation step is necessary in order to include symbol information that VProf uses. Refer to the VProf User Guide for details. Two screenshots of VProf in action are available here. [an error occurred while processing this directive] The VProf package consists of a library and two tools: the graphical tool vprof and the text-based tool cprof. VProf allows you to profile your application in several different ways:
[an error occurred while processing this directive]
The performance counters on a number of different platforms, including Xeon, support hardware interrupt on overflow. You can think of this in the same way that you might with traditional time-based profiling. With time-based profiling, an "alarm" is set periodically. When that alarm expires after some amount of time (the threshold), the program counter is sampled and the position in the program is noted. In the same way, hardware counters that support interrupt on overflow can be programmed to notify software when a given number of a particular event (for example, level 2 cache misses) have occurred. This is a very flexible generalization of traditional statistical profiling techniques. Unfortunately, setting the proper "threshold" at which the alarm will go off is not uniform across events (for example, level 1 cache misses probably occur far more frequently than translation lookaside buffer misses). You will need to adjust the threshold yourself according to the particular hardware event that you are monitoring. At NCSA, VProf has been modified to accept the environment variable VMON_FREQ. You can set this variable to any integer value, which will be used during the run of your program as the interrupt threshold. You'll probably want to experiment with this variable to find a value that gives you the best results: too high of a value will result in an inexact profile, while too low of a value will likely slow down the execution of your application significantly due to excessive calls to the interrupt handler (it's probably best to start high and decrease the value until you are getting reasonable results). By default, VMON_FREQ is set to 100000. [an error occurred while processing this directive] Here are basic instructions for preparing your program for profiling and then using the VProf graphical or text-based tools. You can find more detailed information in the VProf User Guide.
Compiling and linking a single-processor program To compile and link the single-processor program "myprog.f" for VProf-profiling on the Tungsten cluster:
% ifc -c -g myprog.f
% ifc -static -o myprog myprog.o \
/usr/apps/tools/vprof/lib/vmonauto_gcc.o \
-L/usr/apps/tools/vprof/lib -L/usr/apps/tools/papi3/lib \
-lvmon -lpapi
After your program completes successfully, you should have a single file named "vmon.out" that contains the result of profiling.
Compiling and linking an MPI program To compile and link the MPI program "mpiprog.f" for VProf-profiling on the Tungsten cluster:
After your program completes successfully, you should have one or more output files in your working directory. Each will be named "vmon.out.ID", where "ID" is an integer that corresponds to the MPI task ID assigned during the run. To enable automatic profiling of your program (as shown in these examples), you should link in an additional object file, depending on the programming model in use. You can choose from:
Running Your Program and Obtaining a VProf Profile Before you run a VProf-linked program, you should select the type of profiling you'd like by setting the environment variable VMON appropriately (refer to the VProf User Guide for details). For example, to obtain a profile based on the number of total floating point operations during the run of your program as measured by PAPI, you would enter:
% setenv VMON PAPI_FP_OPS
If you've linked your application dynamically, you'll also want to set up your environment properly so that the PAPI shared library can be located at runtime. On Tungsten, you can use the SoftEnv package for this:
% soft add +papi3 Then run your program as you normally would. If all goes well, you will have one or more VProf profiles in your working directory as described above. To view the profiles, all you need to do is to invoke cprof or vprof, supplying the name of your executable program followed by the names of the "vmon.out" files that you'd like to view (you can also do this from inside vprof). For example,
% cprof -e myprog vmon.out
In this example, we provide the option Note that you can supply multiple VProf profiles on the command line (for example, when working with output from multiple MPI tasks) and VProf's tools will present the results in an aggregate form. Here's an example:
% cprof -e myprog vmon.out.0 vmon.out.1 vmon.out.2 vmon.out.3 [an error occurred while processing this directive] Please refer to the VProf User Guide for additional information about VProf. |
|||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||
