[mpiwg-tools] MPI_T usage question: other sensors

[Michael Knobloch]

Hi all,


On 19.12.2013 02:19, Schulz, Martin wrote:
> Hi all,
>
> I agree that a single interface to extract any kind of information from a system (MPI and beyond) would be very helpful and make our tools simpler. As Michael, though, I always thought of PAPI being that unifying interface - it should be very easy to write an MPI_T component to PAPI (in fact, I talked with Dan Terpstra from the PAPI team a few years ago when MPI_T was still under design and he thought that should work) and with that offer all MPI_T counters through PAPI (probably not the control variables, though). This should also allow us to provide "standardized" names for common performance variables (similar to what PAPI does for HW counters).
>

I'm not so sure that writing a PAPI component for MPI_T will be that
simple. It's a while back since I wrote my last PAPI component, but if I
remember correctly such a component requires the names and types of
counters at compile time, which is something that the MPI_T interface
cannot provide. I mean I have no problem to build a PAPI component for
each MPI3 library out there (not that there are too many) or even a
generalized one which queries such information at compile time (although
this might be difficult on frontend-backend archtitectures), but the
standard states that I cannot assume the same set of counters even
between two runs or on different processes (which is horrible btw.).


> The situation changes a bit, though, if MPI implementations query other information, like temperature or power, for themselves (Jeff, was this why you were asking?). In this case, the MPI implementation should use a standardized interface like PAPI itself (to avoid conflicts with tools), which could lead us to some strange circular SW dependencies.
>

I don't even see how that could work in a meaningful way. Querying MPI_T
variables is process local, while several counters (especially such as
power and temperature) are shared between several processes, some even
with restricted access (i.e. only one process might query the counter).
So supporting this is either a huge implementation work or using an
existing interface, i.e. PAPI. And I completely agree with Martin that
we should try to avoid circular dependencies, especially if there's no
real benefit for the user.

-Michael
--
Michael Knobloch
Institute for Advanced Simulation (IAS)
Jülich Supercomputing Centre (JSC)
Telefon: +49 2461 61-3546
Telefax: +49 2461 61-6656
E-Mail: m.knobloch at fz-juelich.de
Internet: http://www.fz-juelich.de/jsc


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------