Hi Junchao, I fully agree with Bill - think of MPI_T not as PAPI, but as perfctr below PAPI (with the same pros/cons). I am actually hoping that we not only do something similar to PAPI at some point, but we'll actually implement an MPI_T PAPI module, which would make all MPI_T variables instantly accessible to a wide range of tools. I had talked to the PAPI group about this a while ago while we wrote MPI_T and we should probably restart that effort. Martin On Oct 29, 2013, at 2:16 PM, William Gropp <[email protected]> wrote:

These might emerge (as they did for PAPI - counters existed long before PAPI). However, implementations are likely to have many different variables. And a problem faced by PAPI uses is even though the names might be the same, then meanings are not always exactly the same.

Portability is also not as big a problem. There just aren't that many distinct MPI implementations.

Bill

William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign

On Oct 29, 2013, at 2:11 PM, Junchao Zhang wrote:

...

MPI_T depends on cvar/pvar names to locate variables. The spec says names are implementation specific. Then, how to make portable tools? If MPI_T is an analog of PAPI, PAPI has standard event names, though not all are available on all CPUs. Do we need an agreement on names of common variables?

Any comments?

--Junchao Zhang _______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA