[mpich-discuss] Extent of support for MPI_T_... interface?

[Halim Amer]

 > I'd read through configure --help multiple times and not noticed
 > this option

You were interested in MPI_T performance variables, which is clearly 
indicated in that configure option. I don't understand how you missed that.

 > which requires a very close read to interpret the implications. It's not
 > the kind of thing you're going to spot immediately even ex post facto
 > without significant prior knowledge. It's not documented or mentioned
 > anywhere else.

Sure, the documentation needs some improvements, but as you guessed, our 
plates are full of with higher priority items. If you have concrete 
suggestions, feel free to let us know or contribute patches.

Keep in mind, however, that what MPI_T exposes is MPI implementation 
dependent. That means, since we are talking about MPICH, you might need 
to be familiar with the MPICH software stack to understand what you are 
measuring. The easiest way for you to understand what performance 
variables we expose, is to pass "all" to  --enable-mpit-pvars and print 
the description of each performance variable (using 
MPI_T_pvar_get_info). While some variables are self explanatory and 
could be applicable to many MPI implementations (e.g., length of message 
queues), others, such as those related to the Nemesis software layer, 
are MPICH-specific and will require understand MPICH deeper.

 > I also think this would more appropriately be a run-time option for 
mpiexec
 > rather than a build-time option for the toolchain itself.

First, multiple builds of the same MPI implementation with different 
performance variables is allowed by the standard. From the MPI 3.1 Standard:

"The number and type of control variables and performance variables can 
vary between MPI implementations, platforms and different builds of the 
same implementation on the same platform as well as between runs. Hence, 
any application relying on a particular variable will not be portable. 
Further, there is no guarantee that the number of variables and variable 
indices are the same across connected processes."

If you care about portability, then don't use the MPI_T interface.

Second, having runtime options to enable-disable tracking performance 
variables would add non-negligible overhead that most users would 
complain about. For instance, adding branches on the critical path 
(e.g., if(message_queue_tracking_is_active) on a MPI_Isend or MPI_Put 
path) to support such runtime option would be too expensive for 
fine-grained communication. Users want MPI communication calls to get 
translated to native hardware with the lowest overhead possible.

 > By the way, just looking through the configure --help output again I 
notice
 > that at least one option: --enable-error-messages-level, doesn't document
 > what the default setting actually is. There may be others.

Thanks for reporting this, we will fix them.

Halim
www.mcs.anl.gov/~aamer

On 6/19/17 10:27 AM, Alexander Rast wrote:
> I have to comment that clearly the documentation needs improvement. It's
> always the last on the priority list, I realise, but this is really very
> obscure. I'd read through configure --help multiple times and not noticed
> this option, and even now the description is highly non-obvious if you
> didn't already know what you were looking for and what it meant. The line
> reads:
>
> '--enable-mpit-pvars=list - selectively enable MPI_T performance variable
> in
>                              modules. list is a comma-separated module
> names,
>                               including (Default is "none"):
>           none     - No performance info recorded
>           recvq    - All message queue-related
>           nem      - All nemesis-related
>           rma       - All rma-related
>           all         - All variables above'
>
> which requires a very close read to interpret the implications. It's not
> the kind of thing you're going to spot immediately even ex post facto
> without significant prior knowledge. It's not documented or mentioned
> anywhere else.
>
> I also think this would more appropriately be a run-time option for mpiexec
> rather than a build-time option for the toolchain itself. There are
> numerous situations where I'd want to have performance monitoring enabled
> for some runs but not others. It doesn't seem to me to be an obvious choice
> to make it a build-time option, and it would be awkward to have 2 separate
> builds. In addition there are the MPICH binary installs available for many
> OS's which ought to have these options available in some form - it would be
> a surprise I suspect to a user who'd installed from a binary image to find
> support disabled for certain features that they'd not even been given the
> option to select.
>
> By the way, just looking through the configure --help output again I notice
> that at least one option: --enable-error-messages-level, doesn't document
> what the default setting actually is. There may be others.
>
>
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss