View source for Performance And Debugging Tools: Niagara

==Memory Profiling ==

<!--
===PurifyPlus===
This is IBM/Rational's set of tools for memory profiling and code testing.  Specifically, the tools are:  purify, purecov and quantify.

In order to gain access to these tools, you need to source the script that defines them to your shell:

  <tt> source /scinet/gpc/Rational/purifyplus_setup.sh </tt>

The documentation for getting started with these tools is in the directory:

 <tt> /scinet/gpc/Rational/releases/PurifyPlus.7.0.1/docs/pdf </tt>

or here: [http://support.scinet.utoronto.ca/Manuals/PurifyPlusGettingStarted_en.pdf PurifyPlus Getting Started].
-->

===Valgrind===

Valgrind http://valgrind.org/ is a suite of tools for debugging and profiling programs especially
useful for finding memory problems, such as memory leaks and segfaults. To use it on the GPC 
you must first load the module valgrind.

 <tt> module load valgrind </tt>

In serial valgrind can simply by run as follows, with no need to recompile your binary

 <tt>valgrind --tool=memcheck ./a.out  </tt>

there are many useful flags such as --leak-check=yes and --show-reachable=yes that
can be found by running valgrind --help on consulting the man pages.

Valgrind can also be used in parallel with MPI as well, http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mpiwrap
in a similar fashion, however a library needs to preloaded first.

 <tt>LD_PRELOAD=${SCINET_VALGRIND_ROOT}/lib/valgrind/libmpiwrap-amd64-linux.so mpirun -np 2 valgrind --tool=memcheck ./a.out </tt>

Besides being a extremely good at [[Performance_And_Debugging_Tools:_GPC#Memory_Profiling | finding memory problems]], [http://valgrind.org/ valgrind] comes with a tool called [http://valgrind.org/docs/manual/cg-manual.html cachegrind] which can find cache use problems in your code; its use is described in our [[Introduction_To_Performance#cachegrind_.28Memory_use_analysis:_GPC.29 | Intro To Performance]].

==Debugging==

===gdb===

[http://www.gnu.org/software/gdb/ GDB] is solid source-language level serial debugger.  [https://support.scinet.utoronto.ca/wiki/images/2/27/Snugdebug.pdf This SNUG TechTalk from Nov 2010] introduces debugging with gdb.    gdb will debug code compiled with both intel and gcc compilers.   Use <tt>module load gdb</tt> to ensure you are using the most recent version of gdb.

<tt>gdb -tui</tt> launches a text-based interface that functions a bit like a gui for debugging code, and can be handy.

<!--
===idbc===

idb is the Intel debugger; it will work with code compiled with both intel and gcc compilers.   Use <tt>module load intel</tt> to ensure the debugger is in your path.   The command-line debugger is launched by invoking <tt>idbc</tt>; launching <tt>idb</tt> will start a graphical, [http://www.eclipse.org/ Eclipse]-based environment, which can be quite slow over a network connection.   If you want nonetheless want to use the graphical interface, ensure that you have Java in your enviroment; ues <tt>module load java</tt>.
-->

===ddd===

[http://www.gnu.org/software/ddd/ Data Display Debugger (ddd)] is a graphical wrapper to the gdb or idb debuggers.  It is quite handy for debugging scientific programs as it has fairly sophisticated data-plotting features where array variables can be plotted dynamically as the program progresses.  As with <tt>idb</tt>, however, using the graphical interface over a network connection can be quite laggy and slow.   Use <tt>module load ddd</tt> to load ddd into your environment.

===ddt===

ddt is Allinea's graphical parallel debugger, in the ddt module. Highly recommended! Use <tt>module load ddt</tt> to load ddt into your environment.

==Performance Profiling==

===gprof===

[http://sourceware.org/binutils/docs-2.19/gprof/index.html gprof] is a very useful tool for finding out where a program is spending its time; its use is described in our [[Introduction_To_Performance#gprof_.28profiling:_everywhere.29 | Intro To Performance]].

===Open|SpeedShop===

[http://www.openspeedshop.org OpenSpeedshop] is a tool for performing sampling and MPI tracing of a program on the GPC.  It's use is outlined in our [[Introduction_To_Performance#OpenSpeedShop_.28profiling.2C_MPI_tracing:_GPC.29 | Intro to Performance]].   It is right now compiled for use only with openmpi and gcc-4.4; to use it,

<pre>
module load gcc openmpi openspeedshop
</pre>

To run a sampling experiment with the program, run the program through openspeedshop then use the same program to view the results:

<pre>
$ openss -f "./a.out" pcsamp
[program runs as usual, outputs extra performance data at the end]
$ openss -f [experimentname].openss
</pre>

It can also trace MPI calls and give detailed statistics about the time spent in MPI routines by process number; to test this on a run done on one of the devel nodes,

<pre>
$ module load gcc openmpi/1.3.2-gcc-v4.4.0-ofed openspeedshop
$ openss -f "mpirun -np 6 ./a.out" mpit
[program runs as usual, outputs extra performance data at the end]
$ openss -f [experimentname].openss
</pre>

this can also be used to perform tracing on batch jobs by ensuring <tt>module load gcc openmpi/1.3.2-gcc-v4.4.0-ofed openspeedshop</tt> is in your <tt>.bashrc</tt> and mpirun-ing the program as shown above.



===Scalasca===

[http://www.scalasca.org/ Scalasca] is a sophisticated tool for analyzing performance and finding common performance problems.  We describe it in our [[Introduction_To_Performance#Scalasca_.28profiling.2C_tracing:_TCS.2C_GPC.29 | Intro to Performance]].