The feedback I am getting back from ISV’s is that the two
most important issues for the C ABI are
1.
Calling convention
2.
Size of input
parameters (e.g., what’s the size of MPI_Comm)
It would be idle to define this across processor architectures,
like x86, x64 etc. but it would be okay to define the ABI across OS/Processor
architecture. These two issues simplify ISV’s testing matrix, and support
ISV’s that are trying to dynamically bind to multiple MPI implementations.
I didn’t hear any ISV ask for unified binary name, and
think that this would be unwise to do so. Having binaries clash with each other
is a deployment nightmare.
Re certification program, I think that it would be wise to have
some mechanism to validate MPI implementations. It is necessary for validating
that an implementation is actually implementing the standard. Test suite compliance
result information would benefit implementers and users.
However, I am not sure that an ABI certification program is
required at this time.
Thanks,
.Erez
From:
owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On Behalf Of William
Gropp
Sent: Monday, December 03, 2007 7:39 AM
To: mpi-21@xxxxxxxxxxxxx
Subject: Re: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan
meeting
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.
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.
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.
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.
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.
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign
|