[mpich-discuss] -mpe=mpitrace not producing any output

[Anthony Chan]

-mpe=mpitrace is a simple profiling library that prints the MPI
calls to stdout.  "mpicc -mpe=mpitrace" is important only during
linking (The option does not do any anything during compilation),
it adds -ltmpe (which you are doing it by hand).  Are all your
MPI calls made in C code ?   

Given you have a big code, and assuming everything is working correctly,
it will print out huge amount of text to your stdout.  
BTW, Have you tried -mpe=mpilog ? It will produce logfile that you can
visualize..

A.Chan

----- "François PELLEGRINI" <francois.pellegrini at labri.fr> wrote:

> mpich-discuss-request at mcs.anl.gov wrote:
> > Message: 2
> > Date: Mon, 5 Jan 2009 13:00:09 -0600 (CST)
> > From: Anthony Chan <chan at mcs.anl.gov>
> 
> > ----- "Fran?ois PELLEGRINI" <francois.pellegrini at labri.fr> wrote:
> >> First, I have trouble using the "mpitrace" feature of MPE.
> >> I compile all of my source code with "mpicc -mpe=mpitrace",
> >> and link the objects with "-ltmpe", but absolutely no output
> >> is produced when I run the compiled program. This both happens
> >> with the official 1.0.8 and r3717 packages. What did I do
> >> wrong ?
> > 
> > just tried -mpe=mpitrace with cpi.c in 
> > <mpich2_108_install_dir>/share/examples_logging,
> > I see trace output appears on my terminal.
> > What program are you trying this ?
> 
> Scotch, the code I develop. It is ~ 100 klines, so difficult
> to reduce it to a small test case.  ;-)
> 
> Scotch has many files. Can it be that the mpitrace flag
> is lost for pure ld operation of mpicc, so that it works
> for the direct compilation of your mono-file example but
> fails for multi-file examples ? I guess so.
> 
> Indeed, as James S Perrin (<james.s.perrin at manchester.ac.uk>)
> reported in another e-mail, the only output I get is a bunch
> of MPI_Finalize reports, which only concern my main object
> file.
> 
> > If the program is small, can you send me the
> > code so I can check/confirm if MPE has any bug ?
> > 
> > In terms of Valgrind, did you configure mpich2 with
> --enable-g=meminit
> > which reduces some valgrind warnings...?  See "configure --help"
> > for more info.
> 
> Yes, of course.
> 
> Dave Goodell wrote:
> > Can you boil this down to a small test program that we can use to
> > reproduce this?
> 
> Nope. Scotch is heavy : can use multiple threads (disabled here not
> to add problems), uses sub-communicators created by MPI_Comm_split,
> does collective communications and immediate sends-recvs on them,
> well, hard to reduce to a test case without losing the semantics
> and trace of the MPI calls.
> 
> >  It's difficult to figure out what's happening without a
> > test program.  A small test program should also help you rule out
> user
> > error such as mismatched send/recv calls.
> 
> I know.
> 
> > As far as the valgrind output is concerned, make sure that you are
> > configuring mpich2 with --enable-g=meminit,dbg (or some superset,
> > including --enable-g=all).  Adding "mem" and "handle" to the
> --enable-g
> > list can also help find certain problems.
> 
> I did it. The string I use is :
> 
> ./configure --prefix=$HOME/mpich/ CPPFLAGS='-I/usr/include/valgrind'
> --enable-error-checking=all --enable-error-messages=all
> --enable-g=all
> --enable-fast=defopt --enable-debuginfo --enable-mpe
> --enable-threads=multiple
> --with-thread-package=posix --disable-f77
> 
> I see nothing wrong with it. I compile each of my library .c files and
> my
> main executables with -mpe=mpitrace, and link the whole with -ltmpe .
> 
> A+,
> 
> 
> 					f.p.