Re: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting

[William Gropp <gropp@xxxxxxxxxxx>]

One important choice that the MPI Forum made was to discuss the semantics first, leaving the syntax (API) to later.  This doesn't mean that the API is less important, just that it is more important to decide on the semantics (and if we even want those semantics) first.  In other words, once you put up an API, there's a large temptation to debate the API rather than the semantics.  There will be plenty of time to discuss the API, and the votes on the full proposal will include the API.  In terms of a presentation, I recommend having a draft API, but not leading with it. 

Bill

On Nov 30, 2007, at 6:28 PM, Richard Graham wrote:

On 11/30/07 6:56 PM, "Douglas Gregor" <dgregor@xxxxxxxxxx> wrote:

On Nov 30, 2007, at 11:26 AM, Richard Graham wrote:

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.

Is there any particular form that these proposal should take, or

perhaps an existing proposal to use as a pattern for new proposals?

I was not part of the mpi-1 or mpi-2 forum, so I will let others say what

was done. I would think it should include:

   - An executive summary

   - A detailed proposal which should include

       - Specific API proposal

       - Semantics

       - Pro's

       - Con's

       - Can this same functionality be obtained within the current

           standard, but maybe in a less convenient manner

       - Discussion of the prototyping work

What is missing ?

Rich

  3.0

  ***

  - Revamped one-sided communications

  - Improved support for generalized requests

  - Non-blocking collectives

  - New support for process fault tolerance

  - Sub-setting functionality

We'll be proposing:

   - support receiving messages of unknown length

- Doug

William Gropp

Paul and Cynthia Saylor Professor of Computer Science

University of Illinois Urbana-Champaign