[Mpi-forum] Discussion points from the MPI-<next> discussion today

Sat Sep 22 03:57:48 CDT 2012

Indeed. The road goes on and on. :)

-----Original Message-----
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of Anthony Skjellum
Sent: Saturday, September 22, 2012 3:00 AM
To: Main MPI Forum mailing list
Subject: Re: [Mpi-forum] Discussion points from the MPI-<next> discussion today

Alexander, 

1) Dropping pairwise ordering is very interesting, esp. if it is a feature to turn on/off per
   communicator.
2) Allowing different communicators to provide different levels of service interesting
3) Having control be reliable, but data not be as reliable might be interesting

Many research areas as well ; what we can standardize is TBD :-)

Tony

----- Original Message -----
From: "Alexander Supalov" <alexander.supalov at intel.com>
To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
Sent: Friday, September 21, 2012 12:58:48 PM
Subject: Re: [Mpi-forum] Discussion points from the	MPI-<next>	discussion	today

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: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] 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" <nmm1 at cam.ac.uk>
To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
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
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 _______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
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

_______________________________________________
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 
_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
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