Hi, Thanks. There may be another interesting twist to that. Imagine we start challenging the initial assumptions (axioms) that lay in the foundation of the MPI standard. Those are, e.g., reliable and pairwise ordered message delivery, non-fairness, and maybe a few more. If we take one out - what happens to the MPI? What part of it survives? What applications become possible that were not possible before? This idea is somewhat comparable to the post-Euclidean geometry, if you wish. E.g., take out the reliable message delivery. This may be perfect for Exascale: you will have to have rather stable algorithms anyway, and loss of a couple of messages should not have dramatic effect then, in this sea of data. And what kind of speedup might be possible with that? Gee. Now, what to take out to get to FT MPI? What part of MPI is amenable to FT? Here we have a possible connection to the subsetting. Best regards. Alexander -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anthony Skjellum Sent: Friday, September 21, 2012 7:46 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] Discussion points from the MPI-<next> discussion today Nick, I think this is a timely e-mail... in practice users in different spaces use somewhat different subsets, and we have said as a group from the beginning that MPI (at MPI-1 level anyway) was the composition of a few concepts and a few features yielding an understandable set of functions, even though people might use a small subset. From what I recall, at the beginning of MPI-2 and MPI-3, efforts to discuss reducing and pruning met with little interest (other than the C++ bindings). What has been elusive, is concrete agreement beyond the 8-16 range of basic MPI functions, are there really subsets of functions that can be agreed on to form 'compliance points'... those could come with or without restricted semantics (e.g., no tags in point-to-point). Another point was made that if you use a layered library, then you don't know what MPI functions it has used, and that subset could be quite different from what the main application uses. In the mid-1990's, a few of us defined one or more embedded subset for constrained embedded multicomputers, such as systems where no more than O(20) functions would ever be used, and where we wanted to get more performance for applications that didn't use tags or wildcards,and where persistent communication was highly preferred, as was the use of pinned/aligned/primed memory for buffers, rather than allowing arbitrary memory. It would be very interesting for future MPI to discuss the advantages of small subsets again. In exascale, where we may have many, many small processors, the size, complexity, and scale of the library and its internal complexity might matter a lot. We might benefit from programs that only use messages from a special heap as well. I do not expect that there would be consensus on this point, but there could be considerable advantage as applications are ported to higher concurrency to remove overheads if they utilize MPI in restrictive ways, and if they are willing to use planned transfers (Send_init, Recv_init, etc). Another benefit of subsetting would be reduced complexity of implementation, with the potential for higher reliability and less dead code in implementations. Furthermore, making a subset of MPI fault tolerant, keyed to what a specific application needs, appears easier than making an entire MPI implementation fault tolerant. Regards, Tony Skjellum ----- Original Message ----- From: "N.M. Maclaren" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> Sent: Thursday, September 20, 2012 12:01:20 PM Subject: Re: [Mpi-forum] Discussion points from the MPI-<next> discussion today For various reasons, the European meetings are at times I find it very hard to attend, but here is a very high-level comment from someone who teaches and advises on MPI, program design / software engineering etc. Something that I would make a plea for is less featuritis - in particular, most MPI users are NOT among the communities that want even most of MPI 2. Before I wrote my course, I did a survey of all of the scientific programs I could get my hands on, and they used a very small subset of MPI 1 with merely a couple of MPI 2 features. If anyone would like the (now rather dated, but sporadically updated) data, please ask. Quite a lot of users have expressed the desire for safely portable and simple subset - which is roughly what I teach, though it's obviously an artificial boundary. But it would help a lot when producing interfaces to other languages, ports to fairly different systems and so on, as well as with learning MPI and teaching it. So not everybody wants more and more - and it's NOT true that we can simply ignore what we don't use - though MPI does pretty well in enabling that. All I request is that people bear this in mind. Regards, Nick Maclaren. _______________________________________________ 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 _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Peter Gleissner, Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052