- Mpi3-abi - mailman3.cels.anl.gov

Re: [Mpi3-abi] Open MPI and ABI
by unknown＠example.com 12 Dec '08

12 Dec '08

ditto here (we are all busy) it may be a short meeting then! At 09:55 AM 12/12/2008, you wrote: >I am sorry Jeff, there was no progress on my front wrt ABI. > >From: mpi3-abi-bounces_at_[hidden] >[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown >Sent: Thursday, December 11, 2008 9:21 AM >To: MPI 3.0 ABI working group >Cc: craig Rasmussen; ddd_at_[hidden]; Ralph Castain >Subject: Re: [Mpi3-abi] Open MPI and ABI > >All, > >At the last meeting I attended (Dublin) we >discussed developing a prototype "morph" ABI >layer with initial implementation targeting the >December meeting. Let's take stock of this >effort when we meet next week. As I recall, >Ezra offered to lead the windows implementation, >and Alexander linux. This exercise is meant to >expose some of the implementation details and >help drive us toward a detailed standard >proposal we can take to the larger group. > >Ezra and Alexander, please brief us on this >effort when we meet next Wednesday. > > >From the Dublin meeting: >MPI ABI standard, separate from MPI API >standard, but under the umbrella of the MPI Forum >Dynamic link is the main objective (binary compatibility) >Startup (mpirun/mpiexec) is a secondary objective >Include all major language bindings in the ABI >standard (C, C++, Fortran) as we go >Tied to MPI 2.1 and forward >Implementers may choose to comply (or not) >May be implemented as a morph layer or native >Initial reference implementation will be a morph layer (tbd who provides) >May be different per platform (Linux, Windows, ) >Different voting rules separate from MPI API forum (?) >Need participation from major implementors in order to make progress > >mpi.h: MPICH 2 (1.0.7) as base with mods as >needed (e.g. max values for compile time values used in declarations) >Proceed with a reference morph layer >implementation targeting (at least) MPICH 2.0, OpenMPI >Load a different module and it just works >Demonstrate with a ring program >Defer startup consideration > >Proof of concept reference morph layer implementations: >Flesh out details by writing some code >Linux on X86-64 cluster Red Hat Linux/SUSE >Windows on X86-64 cluster >Test against ring program >Bring back to the December forum meeting > >see ya next week > >Jeff >_______________________________________________ >mpi3-abi mailing list >mpi3-abi_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi *

1 0

Re: [Mpi3-abi] Open MPI and ABI
by unknown＠example.com 12 Dec '08

12 Dec '08

I am sorry Jeff, there was no progress on my front wrt ABI. From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Thursday, December 11, 2008 9:21 AM To: MPI 3.0 ABI working group Cc: craig Rasmussen; ddd_at_[hidden]; Ralph Castain Subject: Re: [Mpi3-abi] Open MPI and ABI All, At the last meeting I attended (Dublin) we discussed developing a prototype "morph" ABI layer with initial implementation targeting the December meeting. Let's take stock of this effort when we meet next week. As I recall, Ezra offered to lead the windows implementation, and Alexander linux. This exercise is meant to expose some of the implementation details and help drive us toward a detailed standard proposal we can take to the larger group. Ezra and Alexander, please brief us on this effort when we meet next Wednesday. >From the Dublin meeting: *MPI ABI standard, separate from MPI API standard, but under the umbrella of the MPI Forum *Dynamic link is the main objective (binary compatibility) *Startup (mpirun/mpiexec) is a secondary objective *Include all major language bindings in the ABI standard (C, C++, Fortran) as we go *Tied to MPI 2.1 and forward *Implementers may choose to comply (or not) *May be implemented as a morph layer or native *Initial reference implementation will be a morph layer (tbd who provides) *May be different per platform (Linux, Windows, ...) *Different voting rules separate from MPI API forum (?) *Need participation from major implementors in order to make progress mpi.h: MPICH 2 (1.0.7) as base with mods as needed (e.g. max values for compile time values used in declarations) Proceed with a reference morph layer implementation targeting (at least) MPICH 2.0, OpenMPI Load a different module and it just works Demonstrate with a ring program Defer startup consideration Proof of concept reference morph layer implementations: *Flesh out details by writing some code *Linux on X86-64 cluster Red Hat Linux/SUSE *Windows on X86-64 cluster *Test against ring program *Bring back to the December forum meeting ee ya next week Jeff *

1 0

Re: [Mpi3-abi] Open MPI and ABI
by unknown＠example.com 11 Dec '08

11 Dec '08

Dear Jeff, Thanks for the reminder. We did not do anything special on Linux. Intel MPI is (almost) compliant with the proposed ABI by definition, give or take a constant or two. OpenMPI team said they had no resources to support this activity. I did not hear from anyone else on this matter so far. Best regards. Alexander ________________________________ From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Thursday, December 11, 2008 6:21 PM To: MPI 3.0 ABI working group Cc: craig Rasmussen; ddd_at_[hidden]; Ralph Castain Subject: Re: [Mpi3-abi] Open MPI and ABI All, At the last meeting I attended (Dublin) we discussed developing a prototype "morph" ABI layer with initial implementation targeting the December meeting. Let's take stock of this effort when we meet next week. As I recall, Ezra offered to lead the windows implementation, and Alexander linux. This exercise is meant to expose some of the implementation details and help drive us toward a detailed standard proposal we can take to the larger group. Ezra and Alexander, please brief us on this effort when we meet next Wednesday. >From the Dublin meeting: *MPI ABI standard, separate from MPI API standard, but under the umbrella of the MPI Forum *Dynamic link is the main objective (binary compatibility) *Startup (mpirun/mpiexec) is a secondary objective *Include all major language bindings in the ABI standard (C, C++, Fortran) as we go *Tied to MPI 2.1 and forward *Implementers may choose to comply (or not) *May be implemented as a morph layer or native *Initial reference implementation will be a morph layer (tbd who provides) *May be different per platform (Linux, Windows, ...) *Different voting rules separate from MPI API forum (?) *Need participation from major implementors in order to make progress mpi.h: MPICH 2 (1.0.7) as base with mods as needed (e.g. max values for compile time values used in declarations) Proceed with a reference morph layer implementation targeting (at least) MPICH 2.0, OpenMPI Load a different module and it just works Demonstrate with a ring program Defer startup consideration Proof of concept reference morph layer implementations: *Flesh out details by writing some code *Linux on X86-64 cluster Red Hat Linux/SUSE *Windows on X86-64 cluster *Test against ring program *Bring back to the December forum meeting ee ya next week Jeff --------------------------------------------------------------------- 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. *

1 0

Re: [Mpi3-abi] Open MPI and ABI
by unknown＠example.com 11 Dec '08

11 Dec '08

All, At the last meeting I attended (Dublin) we discussed developing a prototype "morph" ABI layer with initial implementation targeting the December meeting. Let's take stock of this effort when we meet next week. As I recall, Ezra offered to lead the windows implementation, and Alexander linux. This exercise is meant to expose some of the implementation details and help drive us toward a detailed standard proposal we can take to the larger group. Ezra and Alexander, please brief us on this effort when we meet next Wednesday. From the Dublin meeting: MPI ABI standard, separate from MPI API standard, but under the umbrella of the MPI Forum Dynamic link is the main objective (binary compatibility) Startup (mpirun/mpiexec) is a secondary objective Include all major language bindings in the ABI standard (C, C++, Fortran) as we go Tied to MPI 2.1 and forward Implementers may choose to comply (or not) May be implemented as a morph layer or native Initial reference implementation will be a morph layer (tbd who provides) May be different per platform (Linux, Windows, ) Different voting rules separate from MPI API forum (?) Need participation from major implementors in order to make progress mpi.h: MPICH 2 (1.0.7) as base with mods as needed (e.g. max values for compile time values used in declarations) Proceed with a reference morph layer implementation targeting (at least) MPICH 2.0, OpenMPI Load a different module and it just works Demonstrate with a ring program Defer startup consideration Proof of concept reference morph layer implementations: Flesh out details by writing some code Linux on X86-64 cluster Red Hat Linux/SUSE Windows on X86-64 cluster Test against ring program Bring back to the December forum meeting ee ya next week Jeff *

1 0

Re: [Mpi3-abi] Open MPI and ABI
by unknown＠example.com 15 Sep '08

15 Sep '08

Jeff, Ralph was not aware of the background of the ABI effort (he is now) when you spoke to him, and that this is a desired capability from the LANL user community. As for committing resources, that's tbd. We may be able to put some effort into the proof of concept morph layer we discussed in Dublin. I suspect Ralph was referring to mods to OpenMPI internals to comply with whatever becomes the ABI spec. Ralph can certainly speak for LANL in that regard. I can imagine that could be a big effort and I understand the sensitivities. As this ABI thing is getting pretty heated, I want to put LANL participation in perspective. When we polled LANL users prior to the start of the forum several user items mapped nicely into the ABI effort. LANL did not initiate this effort but supports it as it addresses several of our user requests, so we joined the working group. The group requested a somewhat impartial third party organization (i.e. not an implementor) to lead the group. We offered to serve as WG lead as a means to get better engaged in the forum and make a contribution. It would be incorrect to say that LANL is "driving" this effort. Our role is more sheparding or facilitating. As you can imagine, LANL is a big place and communication is often less than perfect :>) Jeff At 10:58 AM 9/12/2008, Jeff Squyres wrote: >I told the group in Dublin that I would check with the Open MPI >community to see who wanted to work on the Linux side of the 6- >function ABI proof of concept with our colleagues at Intel MPI. > >Unfortunately, it seems like no one is interested or has the resources >to commit. :-( > >I got feedback through the LANL Open MPI rep that LANL won't be >committing resources to this effort, either, but perhaps Jeff Brown >can double check this (I know there are many more groups at LANL than >just the team with the Open MPI developer). > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi3-abi mailing list >mpi3-abi_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi

1 0

Re: [Mpi3-abi] ABI: for languages?
by unknown＠example.com 12 Sep '08

12 Sep '08

On Fri, Sep 12, 2008 at 07:48:24PM -0400, Jeff Squyres wrote: > If they're not MPI apps, they don't seem relevant to this discussion, do > they? :-) I mentioned this a couple of emails ago, but I'll repeat myself: Because few people distributing MPI apps have even considered making a binary distribution due to the lack of an ABI, it might make more sense to look at how many non-MPI scientific apps are distributed as binaries to get an idea of how much demand for an MPI ABI might be in the future. >> I know that Debian has a ton of scientific apps in it, too, including >> some MPI apps linked only to their favorite MPI implementation. > > Can you get these maintainers to say that they want / will use an MPI > ABI? You are welcome to contantact them. I don't know them. >> The reason all this binary distributing is going on is that end-users >> don't want to compile things, or even rebuild srpms. > > So you're saying: "trust me." :-) No, I am not. You are free to directly contact the BioRPMs people and Debian people to find out their motivation. I was just giving you some clues as to where to find them. -- greg

1 0

Re: [Mpi3-abi] ABI: for languages?
by unknown＠example.com 12 Sep '08

12 Sep '08

On Sep 12, 2008, at 6:27 PM, Greg Lindahl wrote: > http://informatics.umdnj.edu/BioRPMs/ is an example of a group > that's doing > binary distrbiutions. I think these are all non-MPI. > > 36 bioinformatics apps > 11 molecular modeling apps > 29 engineering apps If they're not MPI apps, they don't seem relevant to this discussion, do they? :-) > I know that Debian has a ton of scientific apps in it, too, including > some MPI apps linked only to their favorite MPI implementation. Can you get these maintainers to say that they want / will use an MPI ABI? > The reason all this binary distributing is going on is that end-users > don't want to compile things, or even rebuild srpms. So you're saying: "trust me." :-) Let's hear from the software maintainers, please. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-abi] ABI: for languages?
by unknown＠example.com 12 Sep '08

12 Sep '08

On Fri, Sep 12, 2008 at 06:04:36PM -0400, Jeff Squyres wrote: > On Sep 12, 2008, at 5:59 PM, Greg Lindahl wrote: > >> Sure, you're welcome to ask. But predicting the future is hard, and >> even package maintainers probably aren't very good at it, i.e. someone >> who's never considered a binary distribution due to MPI issues may >> well not leap at the possibility today, but might in a year or two. >> Instead, you might look at the rapid growth of non-MPI scientific >> programs being distributed as binaries, and project from there. > > Can you cite some of these? http://informatics.umdnj.edu/BioRPMs/ is an example of a group that's doing binary distrbiutions. I think these are all non-MPI. 36 bioinformatics apps 11 molecular modeling apps 29 engineering apps I know that Debian has a ton of scientific apps in it, too, including some MPI apps linked only to their favorite MPI implementation. The reason all this binary distributing is going on is that end-users don't want to compile things, or even rebuild srpms. -- greg

1 0

Re: [Mpi3-abi] ABI: for languages?
by unknown＠example.com 12 Sep '08

12 Sep '08

On Sep 12, 2008, at 6:01 PM, Sameer Shende wrote: >> But if there are oodles of PMPI-based tools that want an ABI, I would >> encourage them to publicly speak out -- just like anyone who both >> wants and will actually use an ABI should publicly speak out. > > Yes, there are several PMPI-based tools that want an ABI and the > compatibility you describe. We, in the TAU project > [http://tau.uoregon.edu] will appreciate this very much. Excellent; thanks for the vote. Can you get the other PMPI-based tools to chime in as well? Thanks! -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-abi] ABI: for languages?
by unknown＠example.com 12 Sep '08

12 Sep '08

On Sep 12, 2008, at 5:59 PM, Greg Lindahl wrote: > Sure, you're welcome to ask. But predicting the future is hard, and > even package maintainers probably aren't very good at it, i.e. someone > who's never considered a binary distribution due to MPI issues may > well not leap at the possibility today, but might in a year or two. > Instead, you might look at the rapid growth of non-MPI scientific > programs being distributed as binaries, and project from there. Can you cite some of these? If MPI is being used as general IPC (vs. traditional HPC environments), that could also be a good motivation. But it would be good to see concrete evidence of this first. -- Jeff Squyres Cisco Systems

1 0