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

[Anthony Skjellum]

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