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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss