1. What would such a subset would imply with regard to what I view as support functionality, such as user-defined datatypes, topologies, etc? Ie could this support be easily provided, say by cutting-and-pasting from the full implementation you will still provide? (I now see Torsten recommends excluding datatypes, but what of other stuff?)
2. Even more broadly (and perhaps very ignorantly), can I simply link in both libraries, like -lmpi_subset -lmpi, getting the good stuff from the former and the excluded functionality from the latter? In addition to the application developers use of MPI, all large application programs I’ve dealt with make some use of externally produced libraries (a “very good thing” imo), which probably exceed the functionality in a “subset” implementation.
3. I (basically) understand the adverse performance effects of allowing promiscuous receives (MPI_ANY_SOURCE). However, this is a powerful capability for many codes, and used only in moderation, eg for setting up communication requirements (such as communication partners in unstructured, semi-structured, and dynamic mesh computations). In this case the sender knows its partner, but the receiver does not. A reduction(sum) is used to let each process know the number of communication partners from which it will receive data, the process posts that many promiscuous receives, which when satisfied lets it from then on specify the sender. So would it be possible to include this capability in a separate function, say the blocking send/recv, but not allow it in the non-blocking version?
4. Collectives: I can't name a code I've ever worked with that doesn't require MPI_Allreduce (though I wouldn’t be surprised to hear of many), and this in a broad set of science areas. MPI_Bcast is also often used (but quite often only in the setup phase). I see MPI_Reduce used most often to collect timing information, so MPI_Allreduce would probably be fine as well. MPI_Gather is often quite useful, as is MPI_Scatter, but again often in setup. (Though often “setup” occurs once per time step.) Non-constant size versions are often used. And others can also no doubt offer strong opinions regarding inclusion of exclusion. But from an implementation perspective, what are the issues? In particular, is the basic infrastructure for these (and other collective operations) the same? A driving premise for supporting collectives is that the sort of performance driven capability under discussion is most needed by applications running at very large scale, which is where even very good collect implementations run into problems.
5. Language bindings and perhaps other things: With the expectation/hope that full implementations continue to be available, I could use them for code development, thus making use of things like type checking, etc. And does this latter use then imply the need for "stubs" for things like the (vaporous) Fortran bindings module, communicators (if only MPI_COMM_WORLD is supported), etc.? And presuming the answer to #2 is “no”, could/should the full implementation “warn” me (preferably at compile time) when I’m using functionality that rules out use of the subset?
6. Will the profile layer still be supported? Generating usage can still be quantified using a full implementation, but performance would not be (at least in this manner), which would rule out an apples-to-apples comparison between a full implementation and the subset version with its advertised superior performance. (Of course an overall runtime could be compared, which is the final word, but a more detailed analysis is often preferred.)
7. If blocking and non-blocking are required of the subset, aren't these blocking semantics?
   

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.