[Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting
Supalov, Alexander
alexander.supalov at [hidden]
Thu Feb 21 23:46:53 CST 2008
Hi,
An updated proposal can be found in
http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/AbiWikiPage/
MPI%20ABI%200.4.doc . I kept Track Changes on, so you can easily spot
the changes.
We may want to drop the version number from the file name later on, but
I suggest we keep it on for now, to make sure we can unambiguously refer
to a particular document version.
Your comments and suggestions are most welcome.
Best regards.
Alexander
-----Original Message-----
From: Supalov, Alexander
Sent: Friday, February 22, 2008 5:44 AM
To: 'mpi3-abi_at_[hidden]'
Subject: RE: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting
Hi everybody,
Thanks for a great discussion. A couple of fine points if you permit:
- The current draft ABI proposal is available in
http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/AbiWikiPage/
MPI%20ABI%200.3.doc . I'm going to polish it in the coming few days,
taking into account today's discussion. I'll notify this list once the
new version is available in the Wiki.
- At the moment I consider a morph layer an implementation issue. Note
that a morph layer that binds one a priory unknown MPI ABI to another a
priori unknown MPI implementation is substantially more complex than a
thin stub layer that emulates a known standard ABI on top of one's own,
well known implementation. If the ABI is not wildly different from one's
MPI implementation, the overhead should be manageable.
- Some platforms have more than one well defined calling convention. An
example mentioned at the meeting was the cdecl and stdcall calling
conventions for Windows/IA32. Name mangling, Fortran's 3 different
popular ways of handling string arguments, and Fortran 90 module format
incompatibility come on top of this. Not to mention other potential
issues described in the MPI-2 standard's language interoperability
chapter.
- Coming back to Jeff's comment that any mpi.h includes a C++ binding
and a substantial part of its implementation: this is only pertinent if
one uses a C++ compiler. In case a plain C compiler is used, the C++
part should not be included. I think this happens currently anyway, but
for the proposal to be clean, this may be an additional requirement to
the standard mpi.h.
- Just pointing to a uniformly named MPI library thru LD_LIBRARY_PATH is
not going to work if the MPI libraries have different system library
dependencies. The dynamic linkage compatibility level will have to
address this somehow.
Best regards.
Alexander
-----Original Message-----
From: mpi3-abi-bounces_at_[hidden]
[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Solt, David
George
Sent: Friday, February 22, 2008 12:33 AM
To: Mpi3-abi_at_[hidden]
Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting
Attendees:
Jeff Brown (meeting organizer), David Daniels (open MPI / LAM
developer), Nathan DeBardeleben (Los Alamos), Fredrick Ellis (end user,
didn't catch an affiliation), Jeff Squyres (Cisco), Alexander Supalov
(Intel), Erez Haba (Microsoft), Kannan Naraasimhan (HP), David Solt (HP)
1. Introductions.
Variety of backgrounds including developers, end users who work with
many applications & MPI's, and industry implementers who work with many
ISV's.
2. General Statement of Goals:
For reference, here is our original charter as put forth by Jeff B.:
"To define any additional support needed in the MPI standard to enable
static and dynamic linkage compatibility across MPI implementations on a
target platform for MPI based Applications."
* avoid separate compiles for each MPI implementation.
* note that beyond mpi/application combinations, we also have
compiler/mpi combination issues.
* possible scopes for our efforts:
- Compile time (should be covered by the current MPI
standard)
- Link time (object level compatibility)
- Run time (simply "point" (LD_LIBRARY_PATH, for
example) to a different MPI). Clearly more difficult but potentially
more beneficial than link time.
* An ABI should reduce the # of executable flavors users or
ISV's most provide.
* Some ISV's are qualified to a specific build of a specific MPI
and they will not benefit for any ABI changes.
3. Languages
Which bindings should be included in our efforts?
* Should any efforts be directed to all bindings or just C?
- A C-only solution may be perceived as contrary to the
style of the standard.
- It was also noted that MPI introduced language
bindings in phases, we could follow suite.
* Compilers introduce name mangling issues and C++ is
particularly difficult do to the inlining that occurs.
* Fortran has more manageable name mangling issues, but also has
the problem of .TRUE. & .FALSE. definitions.
* Appeared to be some consensus that a C-only solution would be
a good starting point.
4. Details of what we might define
* A morph layer vs. a 'true' ABI compatibility.
- morph layer is perceived as additional overhead.
- morph layer is simpler for implementers who may be
heavily invested in current header files, etc.
[[ NOTE: I'm unsure if the morph layer is an implementation
issue or does it genuinely change our direction ]]
* Possible targets for standardization: mpi.h, name resolution
of libraries
- Almost any interesting definition of ABI compatibility
will need some level of standardization of mpi.h
- If we can just point to a different directory with
LD_LIBRARY_PATH, then applications need to be linked against the same
library names, regardless of MPI implementation.
* Discussion of whether calling conventions are an issue or is
it just a matter of fixing mpi.h?
- Most industry standard platforms have a well defined C
calling interface.
5. Should ABI compliance be optional?
* Forcing all implementations to adhere to a standard may be too
great a burden to implementers (detracting them from more
interesting/useful work).
* Some implementations are on hardware or OS where only one
implementation exists and is likely to ever exist. Should they have to
'pay' the cost to claim full MPI compliance.
* Appeared to be consensus that ABI compliance and MPI
compliance should be separated out:
- An implementation can be MPI compliant even though
they are not ABI compliant.
- Similar to mpiexec definition (recommended, if you
provide it must look "this way", but not required)
- A separate "stamp/claim" for being ABI compliant.
6. Next steps
* For this week: post minutes to e-mail, then
Twiki after acceptance.
* For next week: Schedule next conference call
* For march meeting: define the goal of the working group.
Exactly what are we trying to accomplish.
* General: Discuss via e-mail prior to next
meeting?
[[ NOTE: did not appear to be a resolution on this ]]
* General: How will the outcome of our
discussions will get turned into a proposal.
[[ NOTE: do we need to assign an owner? ]]
* General: How will the outcome of our
discussions will get turned into actual MPI standard text as the current
presentation style of the Standard is derived from its focus on API's
(not ABI's).
_______________________________________________
Mpi3-abi mailing list
Mpi3-abi_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi
---------------------------------------------------------------------
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.
More information about the Mpi3-abi
mailing list