[Mpi-22] MPI_INIT assertions
alexander.supalov at [hidden]
Thu May 15 10:33:55 CDT 2008
Re. MPI_Info before MPI_Init: if special MPI initialized or owned memory
is used for implementing MPI_Info, getting it initialized ahead of the
MPI_Init may be tough. If bit flags are appropriate for assertions, I'd
say we should go with that, and possibly fold required threading support
level into them as well, as discussed earlier.
From: Supalov, Alexander
Sent: Thursday, May 15, 2008 5:31 PM
To: 'MPI 2.2'
Subject: RE: [Mpi-22] MPI_INIT assertions
We can pretty well pass data back and forth via MPI_COMM_WORLD attribute
already now. This may be too late for assertions proposed by Rick, but
seems adequate for everything else, provided we can describe how an
implementation should react to the attribute setting action, and what
attributes it should attach to the MPI_COMM_WORLD by default. Same with
windows and files.
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham
Sent: Thursday, May 15, 2008 5:26 PM
To: MPI 2.2
Subject: Re: [Mpi-22] MPI_INIT assertions
We should be careful about making a change in MPI 2.2, knowing that we
will likely turn around again
in MPI 3.0 and change things again. If we are talking about changing
the interface in 2.2, and
then extending the assertions/hints in 3.0, this seems fine, but if we
may want to change the
interface yet again in 3.0, we should rethink things.
I will add that if we are going to add some sort of "info" argument to
'MPI_Init()', we should deprecate
MPI_Init() and MPI_Init_thread(), and include the threading
specification in the "info" object.
Finally, before we decide on how to pass hints/assertions (if we do) to
MPI_Init(), we should
define a consistent way across the standard for passing information
between the application and
the library, as this is not the only instance where this is useful, and
a uniform way of doing this
makes things much easier on users.
On 5/14/08 9:14 AM, "Richard Treumann" <treumann_at_[hidden]> wrote:
MPI_Init time assertions must be few and each must be valuable
or the concept will fall like a house of cards.
There is nothing in my proposal for MPI_Init time assertions
that rules out providing other mechanisms in MPI 3 for giving guidance
to the MPI implementation. In MPI 3 we can consider more hints and we
can add the abiility to give stronger direction to MPI or provide it on
a more granular basis - If it makes sense. These extra mechanisms are
far to complex to consider as part of MPI 2.2.
I would not use the phrase that Dries does when he says
"Assertions are bad" but I agree with the the sentiment behind his
statement. I think there should be a very small number of assertions
defined in the standard and for each there should be a good rationale.
For MPI 2.2 there should be a great rationale because we can come back
in MPI 3 and add more assertions if we miss some important ones. It is
much harder to remove one that turns out to be real trouble.
Each assertion the the MPI Standard defines has the potential to
break some piece of code that is valid MPI but that depends on semantic
the assertion says is optional. The author of the routine that calls
MPI_Init has the power to declare assertions and the authors of other
parts of an applicaton must either live within the rules or explicitly
shield against them.
For project teams that develop complete applications, the
decision to use an assertion belongs to the team, team leader or
architect. If it is decided that an application will use a specific
assertion it is the team lead who must make sure all developers
understand the decision and write appropriate code. All testing will be
done with the assertion in place.
For third part libraries, the only option is to either forbid
all assertions or explicitly pick some to allow. If there are 4
potential assertions, it is not very hard to decide for each one - "Will
the library tolerate it?". If there are 50 assertions, library authors
will seldom allow them all and will be more tempted to just say "No
assertions allowed" because making judgements about each of 50 is too
For Community developed code where people contribute source but
are not under direct control of an architect or team lead, reviewing
each submission for compliance with one or two assertions may be
acceptable but reviewing for 50 each time somebody contributes new code
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi-22-bounces_at_[hidden] wrote on 05/14/2008 07:21:41
> * Terry Jones <trj_at_[hidden]> [2008-05-13 15:19:07]:
> > You can also imagine other possibilities to provide helpful
> > instance, perhaps the user could provide Assertions that
would help MPI IO
> > with read-ahead prefetching or write-behind, or even
> > (e.g., later I will be creating one file per MPI task).
> Things like read-ahead or write-behind clearly shouldn't be
> hints. (And, probably 'one file per MPI task' too -- if this
is still going to
> be needed in 2 years)
> MPI already has hints that can capture some of the things
> access_style: (read_once, write_once, read_mostly,
> reverse_sequential, and random)
> sequential -> this can easily be used to turn on
> IF THE MPI LIBRARY decides this is useful
> Assertions are bad -- they break compatibility -- and should
> tolerated if they provide real benefits and if the same cannot
> through existing mechanisms (hints, ...).
> In the examples mentioned, this is not the case.
> [attachment "attia6gr.dat" deleted by Richard
> mpi-22 mailing list
mpi-22 mailing list
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mpi-22