Use the Profiling/PC Sampling task selection when you are identifying which parts of your program are using the most CPU time. PC profiling results in a statistical histogram of the program counter. The exclusive CPU time is presented as follows:

This task gathers data by sampling the program counter (PC) value every 10 milleseconds (ms).

Use the User Time/Callstack Sampling task selection to tune a CPU-bound phase or program. It enables you to display the time spent in the CPU by function, source line, and instruction. This task records the following:

Data is measured by periodically sampling the call stack. The program's call stack data is used to do the following:

The time spent in a procedure is determined by multiplying the number of times an instruction for that procedure appears in the stack by the average time interval between call stacks. Call stacks are gathered whether the program was running or blocked; hence, the time computed represents the total time, both within and outside the CPU. If the target process was blocked for a long time as a result of an instruction, that instruction will show up as having a high time.

User time runs should incur a program execution slowdown of no more than 15%. Data from a usertime experiment is statistical in nature and shows some variance from run to run.

Use the Ideal Time/Pixie task selection to tune a CPU-bound phase. The name ideal time is a historical name first used when processors would execute instructions in a more linear manner than the current modern processors do. Ideal time experiments would represent the best possible performance for your program.

The analysis determines the cost on a per-basic block basis; it does not deal with data dependencies between basic blocks. A basic blocks is a set of instructions with a single entry point, a single exit point, and no branches into or out of the instructions. It is useful when used in conjunction with the Profiling/PC Sampling task. Comparing the two lets you examine actual versus ideal time. The difference is the time spent as a result of the following:

This task records the following:

The following results can be displayed in the function list, the Source View, and the Disassembly View:

The task requires instrumentation of the target executable. Counter code is inserted at the beginning of each basic block.

After the instrumented executable runs, the Performance Analyzer multiplies the number of times a basic block was executed by the number of instructions in it. This yields the total number of instructions executed as a result of that basic block (and similarly for other specific kinds of instructions, like loads or stores).

While ideal time creates a complete call graph and points out where the program spends the most time if the processor was linear in execution of instructions, it is best to run a PC sampling experiment also and compare the results.

The following is a typical case of why ideal time is not enough to learn about application performance. Because ideal only knows about instructions executed and the number of times a cycle has been executed, the loop

DO i=1,size
   DO j=1,size
      DO k=1,size
         u(i,j) = u(i,j) + v(i,k)*w(k,j)
      END DO
   END DO
END DO

would be the same for ideal as

    DO j=1,size
DO i=1,size
         u(i,j) = u(i,j) + v(i,k)*w(k,j)
      END DO
   END DO
END DO

and the same as

       DO k=1,size
   DO j=1,size
DO i=1,size
         u(i,j) = u(i,j) + v(i,k)*w(k,j)
      END DO
   END DO
END DO

But if you run it, just by using time or timex, you will see big differences.

Remember that ideal knows nothing about software pipelining, memory, page faults, caches, etc. only plain instructions executed one after another. It just counts the number of times each instruction was executed.

So, accessing u(i,j) or u(j,i) is the same for ideal, but it can make a big difference for the application runtime performance.

Use the Floating Point Exception Trace task selection when you suspect that large, unaccounted for periods of time are being spent in floating-point exception handlers. The task records the call stack at each floating-point exception. The number of floating-point exceptions is presented as follows:

To observe the pattern of floating-point exceptions over time, look in the floating-point exceptions event chart in the Usage View (Graphical) window.

Use the I/O Trace task selection when your program is being slowed down by I/O calls, and you want to find the responsible code. This task records call stacks at every read(2), write(2), readv(2), writev(2), open(2), close(2), pipe(2), dup(2), and creat(2) system call. It also records file descriptor information and the number of bytes read or written.

The number of bytes read and written is presented as follows:

Use the Memory Leak Trace task selection to determine where memory leaks and bad calls to free may occur in a process. The task records the call stacks, address, and number of bytes at every malloc, realloc, and free call. The bytes currently allocated by malloc (that might represent leaks) and the list of double calls to free are presented in Malloc Error View and the other memory analysis views. The number of bytes allocated by malloc is presented:

If you are running your application on a system using either the R10000 or the R12000 series CPU, you can use the R10k/R12k Hardware Counters task selection from the WorkShop Debugger window once you have focused in on the source of your problem. This task gives low-level, detailed information about hardware events. It counts the following events:

You can also choose hardware counter profiling based on either PC sampling or call stack sampling.

You can generate other hardware counter experiments by using the ssrun command. See the ssrun(1) man page or the SpeedShop User's Guide for more information.

Use the Custom task selection when you need to collect a combination of performance data that is not available through the predefined tasks. Selecting Custom brings up the same tab panel screen displayed by the Configs... selection (see Figure 5-1).

The Custom task lets you select and tune the following:

Remember the basic warnings in this chapter about collecting data: