[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.



--
Jeff Squyres
Cisco Systems