[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting
- To: <mpi-21@xxxxxxxxxxxxx>
- Subject: RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting
- From: "Supalov, Alexander" <alexander.supalov@xxxxxxxxx>
- Date: Mon, 3 Dec 2007 11:05:59 -0000
- Delivered-to: mpifrm-mpi-21-outgoing@mailbouncer.mcs.anl.gov
- Delivered-to: mpifrm-mpi-21@mailbouncer.mcs.anl.gov
- In-reply-to: <C375CE31.116A1%rlgraham@ornl.gov>
- References: <C375CE31.116A1%rlgraham@ornl.gov>
- Reply-to: mpi-21@xxxxxxxxxxxxx
- Sender: owner-mpi-21@xxxxxxxxxxxxx
- Thread-index: AcgzhvihNyHS8J96EdylTgAX8sZF7gCD6wEQ
- Thread-topic: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting
Hi everybody,
I think the ABI topic should be accompanied by definition of the
validation/certification procedure, be that a comprehensive test suite
with predefined outcomes or such. Having a common ABI and still behaving
differently on some applications won't help customers move between MPI
implementations, which is a common ABI is primarily intended for. By the
way, the ABI extends beyond the function interface - it includes library
naming, process startup, etc.
About the Java, C#, and other "new" interfaces: if they are really
necessary, the Forum for me is the only place where "official" MPI
bindings can be approved. They may be developed elsewhere, but if
somebody want their binding to achieve that status, they should come up
with a proposal and work with or, better, in the Forum.
One worthy MPI-3 topic would be a new edition of the unified standard
document (MPI-1 + MPI-2 + MPI-3). It's just plain inconvenient to go
thru so many different books and, hopefully not for long, multiple
errata. I see that MPI-2 will be proofread for the January meeting. Is
there an intention to unify the standard documents later on?
Finally, there's this never dying controversy around making no MPI calls
and making progress (see the August-September discussion related to the
generalized requests, for one). Do we want to clarify this in the
standard once and forever in unambiguous terms? This may even be an
MPI-2.1 item, by the way.
Best regards.
Alexander
--
Dr Alexander Supalov
Intel GmbH
Hermuelheimer Strasse 8a
50321 Bruehl, Germany
Phone: +49 2232 209034
Mobile: +49 173 511 8735
Fax: +49 2232 209029
-----Original Message-----
From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On
Behalf Of Richard Graham
Sent: Friday, November 30, 2007 8:27 PM
To: mpi-21@xxxxxxxxxxxxx
Subject: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan
meeting
This is a call for items to be included on the agenda for the Jan
meeting of
the MPI Forum. These should be items that people want to consider for
the
2.2 and 3.0 (we have not agreed on what these will be called) version of
the
MPI standard.
As before, what these need to be are real proposals, i.e. we need to
have a
solid proposal for the change/addition being proposed, with pros and
cons.
Given the meeting time, I don't expect that we will have time for a more
than four items for 2.2, and one or two for 3.0. Given the limited
time, I
expect that, depending on the number of agenda items, this will be an
opportunity to start the discussions on these topics, but not much more
than
this. It would be good to circulate any of these proposals to the
mailing
list at least one week prior to the meeting (e.g. By 1/7/2008) to allow
people time to study these proposals. The items that have been
mentioned so
far (and will need champions with concrete proposals, if these are to be
addressed) are
2.2 (I expect some of these may need to move to 3.0)
****************************************************
- adding the const declaration to a select set of API arguments
- ABI
- send buffer access
- Changing count arguments from an MPI_Int to a type that will
accommodate
values larger than 2^32
3.0
***
- Revamped one-sided communications
- Improved support for generalized requests
- Non-blocking collectives
- New support for process fault tolerance
- Sub-setting functionality
Rich
---------------------------------------------------------------------
Intel GmbH
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.