[Mpi-forum] ticket 273

[Anthony Skjellum]

Folks, I enjoyed the meeting in Tsukuba very much, and the discussions were illuminating!

I am personally very disappointed that we are not orthogonalizing the design of MPI-3
to have non-blocking collective operations for all collective operations.  This seems
like a very short-sighted decision, and we will have to revisit.   Orthogonalization of
design is what designers of systems like this do.  To complement that, we need builders of
big parallel codes and products to come to the meetings, and make sure we meet their needs,
not interpreted as second or third hand.  

Given all the efforts to look at MPI for exascale going on, recognition of non-blocking
operations to support overlapping of communication, computation, and I/O, as well as allow
scheduling to be divorced from the user thread, and reduce polling (and reduce jitter)
appear crucial.

A design rule proposed for MPI-3.x, x>0: We decide to support first-class non-blocking collective 
operations.  It spreads to the entire standard.  We then make exceptions on how to handle cases that 
might not make sense.  The design principle drives a global change, and then each operation gets
validated as relevant.   Exceptions limiting that choice are made based on logic, not implementation
effort or one-off anecdotal experience to the contrary.

We should not have selective non-blocking operations, selectively leave split phase here and there,
and tell users that they can have Comm_idup () which is superb of course, but not Comm_isplit(), which
is even more useful IMHO.  I use that just as an example of lack of orthogonality, please don't focus on
this point.  Even though individual arguments about past success/failure with a particular function
should not defeat orthogonality as the design principle.  We are after all trying to enable a 
concept to work, and allow applications to exploit that concept: same as with I/O as a concept,
1-sided as a concept, collective operations as a concept.

I propose that the entire December meeting be focused on design, design orthogonalization, and big-picture
roadmap/plans for MPI beyond 3.0, not to incremental additions.  We need to decide that soon, so we recognize
that July and September meetings are close outs on MPI 3.0, and business as currently done.  And it starts
with a short post-mortem on MPI 3.0, what we achieved, what the impact is of the new changes, what the timespan
is before users get 3.0 and etc. 

Why go forward with MPI 3.x, x>0 without deeper agreed-on, enforced principles driving our further work?
While it is intellectually very interesting, aren't we all trying to support users and systems and roadmaps
with a standard?

1) Make MPI ready for exascale (such as: predictability, scalability, low jitter, fault resilience)
2) Work with modern programming languages in a first-class way (e.g., C++, not just Fortran latest and C89)
3) Drive to broader applicability to HPC and beyond
4) Being fully 64-bit clean
5) Remove functionality, if appropriate, that impairs these goals

Note: Some of the work of the last 4 years fits obviously here, though not yet accepted, such as FT, 
or collective non-blocking I/O.   Other items that appear very interesting were simply delayed due to fatigue
or who was able to be present this week to vote.

In two years (or whatever the appropriate span of time) for 3.x, we should work these big pictures, driven by high-level 
design decisions that inform classes of functionality, rather than just individual functions.

Regards,
Tony

----- Original Message -----
From: "Mohamad Chaarawi" <chaarawi at hdfgroup.org>
To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
Sent: Wednesday, May 30, 2012 2:34:44 PM
Subject: [Mpi-forum] ticket 273

Hi All,

I'm still trying to figure out why ticket 273 was voted down. At the 
last meeting, I would say there was a consensus that the non blocking 
collective I/O ticket (273) was ready to be voted in. Nobody expressed 
an objection after me removing the shared file pointer nbc routines and 
re-reading the draft. All the I/O chapter committee reviewed the draft 
and commented on the ticket that it looks good.

At the Japan meeting, we get 8 yes , 2 nos, and 6 abstains, which under 
the new rules marks the ticket as failed.
None from our organization could attend the meeting to really understand 
what the 2 no votes were for, and why 6 organizations abstained.
If the abstains are because people don't care or don't understand what 
is being voted on or missed the vote (which are the reasons why I vote 
abstain), then the new voting rule doesn't really make sense. If the 
abstains where for something else, then the votes should be NO. So could 
someone mention why this was voted down?

Thanks,
Mohamad

_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- 
Anthony Skjellum, PhD
Professor and Chair
Dept. of Computer and Information Sciences
Director, UAB Center for Information Assurance and Joint Forensics Research ("The Center")
University of Alabama at Birmingham
+1-(205)934-8657; FAX: +1- (205)934-5473

___________________________________________
CONFIDENTIALITY: This e-mail and any attachments are confidential and
may be privileged. If you are not a named recipient, please notify the
sender immediately and do not disclose the contents to another person,
use it for any purpose or store or copy the information in any medium.

Please consider the environment before printing this e-mail