[Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting
Jeff Brown
jeffb at [hidden]
Tue Feb 26 10:53:33 CST 2008
these are good points - thanks
I hadn't considered the backward compatibility issue.
Jeff
At 09:14 AM 2/26/2008, you wrote:
>Since I was taking notes, I did not voice many of my thoughts in our
>last meeting. Let me add some of my own thoughts:
>
>1) HP-MPI's experience around mpi compatibility is primarily around
>the use of 3rd party libraries such as scalapack. I am unsure if
>these libraries are distributed with multiple builds for different
>MPI implementations. I do know that HP-MPI's translation layer to
>MPICH-based compatibility is frequently used in this context. I'm
>not sure how this information impacts what we are trying to
>accomplish, but I wanted to point out that 3rd party libraries are
>another motivating factor.
>
>2) I also have concerns around our (abi working group)
>efforts. Some MPI implementations maintain ABI compatibility
>between releases, so users can upgrade to the newest release without
>rebuilding. If an "official MPI ABI" is defined, they may be very,
>unlikely to stop providing compatibility to current ABI. I think
>such implementations have two options:
>
> a) Provide a morphing layer from the offical MPI ABI to
> their historic ABI. In this case, I am concerned that if ISV's
> perceive that this morph layer incurs any cost whatsoever, they
> will continue to generate and distribute an executable that is
> linked to the historic implemnation-specific ABI. In the end, the
> effect could be an increase in the number of executables that ISV's deliver.
>
> b) Adopt the "official MPI ABI" as their native
> distribution and provide a morph layer for backwards
> compatibility. This would take a lot of faith on their part that
> other implementations will embrace the official ABI and make the
> effort and the perceived hit to using their historic native-ABI worth while.
>
>After getting bitten by efforts such as IMPI, HP-MPI, for example,
>would have to give this a lot of thought before deciding on option B.
>
>Thanks,
>Dave Solt
>
>
>-----Original Message-----
>From: mpi3-abi-bounces_at_[hidden]
>[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown
>Sent: Friday, February 22, 2008 11:15 AM
>To: mpi3-abi_at_[hidden]
>Subject: Re: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting
>
>Thank you for taking notes. You captured the key discussion points
>quite well.
>
>Here's what I took away from the meeting:
>1. the group will initially focus on an MPI ABI for C bindings only
>(can't solve all the worlds problems at once)
> note that this avoids dealing with the fortran compiler symbol
> name issues
> the goal is run time dynamic link compatibility (just change
> LD_LIBRARY_PATH (for unix)) 2. the work to accomplish this is two fold
> - define a reference mpi.h to include "standard" types, scope
> and values for constants
> - ensure consistent linkage conventions (I don't think this is
> an issue on unix platforms) 3. consider a "MPI ABI compliant"
> certification rather than including this in the general MPI 3.0 standard
> frankly I have concerns about this - I'm afraid implementors
> may just blow it off
>
>Next steps:
>- come to consensus on working group goals as input to a proposal
>- develop a short briefing to convey this for the March meeting
>
>If we need another telecon that can be easily set up. Let me know
>if you think this is necessary.
>
>Thanks for your participation - we are off and rolling!
>
>Jeff
>
>At 04:33 PM 2/21/2008, you wrote:
>
> >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
>
>
>_______________________________________________
>Mpi3-abi mailing list
>Mpi3-abi_at_[hidden]
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi
>
>_______________________________________________
>Mpi3-abi mailing list
>Mpi3-abi_at_[hidden]
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi
More information about the Mpi3-abi
mailing list