Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] ompi_info
From: David Goodell (dgoodell) (dgoodell_at_[hidden])
Date: 2013-07-18 11:17:32

On Jul 18, 2013, at 9:53 AM, Ralph Castain <rhc_at_[hidden]> wrote:

> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) <dgoodell_at_[hidden]> wrote:
>> On Jul 18, 2013, at 8:06 AM, Ralph Castain <rhc_at_[hidden]> wrote:
>>> That's a good point, and a bad behavior. IIRC, it results from the MPI Forum's adoption of the MPI-T requirement that stipulates we must allow access to all control and performance variables at startup so they can be externally seen/manipulated.
>> Minor nit: MPI_T does not require this. However, it does recommend that you offer users access to as many variables as possible as early as reasonably possible for the convenience and control of the user.
>> If an implementation chooses to offer 5% of the possible control/performance variables to the user just before MPI_Finalize, that's still a valid MPI_T implementation. But it may not be a very useful one...
> The problem here is one of use vs startup performance. George is quite correct with his concerns - this behavior would have been a serious problem for RoadRunner, for example, where we had a small IO channel feeding a lot of nodes. It will definitely become an issue at exascale where IO bandwidth and memory will be at a premium.

My point was not that the performance concerns were unfounded. Rather, I wanted to point out that the "load everything" behavior is not a hard requirement from the MPI standard, so we have room for different implementation choices/tradeoffs.