Re: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting

[William Gropp <gropp@xxxxxxxxxxx>]

There's one more thing to remember about the ABI discussion - not all MPI target platforms are commodity clusters.  Specifying an MPI ABI would be like specifying the C ABI, including the call interface.  This doesn't mean that there aren't interesting ABI discussions about MPI (or C or Fortran or POSIX or ...) on particular classes of platforms, but an "MPI ABI" that applied to all platforms would be a bad idea.  

Bill

On Dec 3, 2007, at 8:48 AM, Terry Dontje wrote:

I compeletely agree that we don't want to ask an open-ended question(s) and that we need ask things that are fairly quantifiable.  This leads me to believe that the general topic/proposal for ABI at the next  (first) Forum meeting may be premature.  Maybe a group of ABI interested (for and against) parties should meet at the MPI Forum (or possibly via email and concall) to discuss this survey.

With the above in mind I have a feeling that discussing the survey idea for the rest of the Forum/standard process at the next Forum might be useful. 

--td

Jeff Squyres wrote:

An excellent idea (survey the users).

Might I suggest that if we survey the users, don't just give them an open-ended "what do you want?" question, but rather a series of targeted questions that have quantifiable answers.  You can follow it at the end with an open-ended question ("Is there anything else you want from an ABI that was not covered above?") to catch anything that was missed, such as whacky user ideas that the Forum hasn't thought of.

My point is that if we collect data from users, it would be most helpful to have as much of it in a quantifiable form as possible.  Having lots of data is one thing; having lots of data that is easy to analyze and understand is a different thing -- questions must be specifically setup to obtain this goal.

I would also suggest that such a questionnaire should easily be hostable on www.mpi-fourm.org.  :-)

On Dec 3, 2007, at 9:17 AM, Terry Dontje wrote:

I agree with Jeff that this ABI topic can be a blackhole, definitely lots areas one could attack.

However, I've had some requests from ISV's that an ABI would be helpful.  Because of that I

think Steven's idea of surveying the users of MPI may allow us to clarify what users really want

when they ask for an ABI.  It may also be useful to encourage the users wanting the ABI to attend

one of the Forum meetings so a discussion can be had.

Note by users I mean application developers using the MPI API.  This would include the group of

ISVs, Government Labs or other corporations that may use the API.

--td

Jeff Squyres wrote:

On Dec 3, 2007, at 6:05 AM, Supalov, Alexander wrote:

I think the ABI topic should be accompanied by definition of the

validation/certification procedure, be that a comprehensive test suite

with predefined outcomes or such. Having a common ABI and still behaving

differently on some applications won't help customers move between MPI

implementations, which is a common ABI is primarily intended for.

I think that if we start defining the specific interpretations of the MPI standard, it will result in a black hole of despair.  In pragmatic terms, there are many places where the MPI spec could be clarified to get more consistent behavior from all the various MPI implementations.  In many other places, the Forum intentionally left the decision up to the implementor.

By the

way, the ABI extends beyond the function interface - it includes library

naming, process startup, etc.

This is also a tangled pit of woe.

These are two reasons that I am not optimistic about an ABI.

About the Java, C#, and other "new" interfaces: if they are really

necessary, the Forum for me is the only place where "official" MPI

bindings can be approved. They may be developed elsewhere, but if

somebody want their binding to achieve that status, they should come up

with a proposal and work with or, better, in the Forum.

Are there any languages that cannot have 3rd party MPI bindings by layering on top of C MPI bindings?

Re-stating a mantra: it's very suspicious for a vendor or researcher to say "I have an idea that *must* be standardized!"  It's much more useful to have real-world proof that applications want/need it.  Many of the most successful aspects of MPI had years of real-world experience behind them -- the standard was just codifying what was already common practice.  Some of the least successful aspects of MPI were done because they were a "good idea" or had a political motivation, but lacked a reference implementation or apps developers saying that they wanted it.

One worthy MPI-3 topic would be a new edition of the unified standard

document (MPI-1 + MPI-2 + MPI-3). It's just plain inconvenient to go

thru so many different books and, hopefully not for long, multiple

errata. I see that MPI-2 will be proofread for the January meeting. Is

there an intention to unify the standard documents later on?

It would certainly be useful to do so.

Finally, there's this never dying controversy around making no MPI calls

and making progress (see the August-September discussion related to the

generalized requests, for one). Do we want to clarify this in the

standard once and forever in unambiguous terms? This may even be an

MPI-2.1 item, by the way.

FWIW: user progress (generalized requests) and MPI core progress are subtly different issues, IMHO.

William Gropp

Paul and Cynthia Saylor Professor of Computer Science

University of Illinois Urbana-Champaign