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" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> 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 [email protected] 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