From alexander.supalov at [hidden] Thu Feb 7 14:07:59 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Thu, 7 Feb 2008 20:07:59 -0000 Subject: [Mpi3-abi] ABI Working Group In-Reply-To: <6.2.3.4.2.20080207111049.031cad60@ccs-mail.lanl.gov> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A20104643C@swsmsx413.ger.corp.intel.com> Hi everybody, I've just uploaded an updated proposal version 0.3 to the ABI Wiki page (see http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage). Best regards. Alexander -----Original Message----- From: Jeff Brown [mailto:jeffb_at_[hidden]] Sent: Thursday, February 07, 2008 7:17 PM To: Supalov, Alexander; Edric Ellis; Narasimhan, Kannan; Erez Haba; Christian.Bell_at_[hidden]; Solt, David George; sameer Shende Cc: Nathan DeBardeleben; ddd_at_[hidden]; jeffb_at_[hidden] Subject: RE: ABI Working Group all, Let's start using the ABI WG email list so that the discussions will be archived, etc. To subscribe, link to: http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi Rich is encouraging all the working groups to have a mid term telecon some time within the next couple of weeks. I think we should do that as well. In preparation for the telecon, let's do some work on the draft proposal Alexander kicked off then discuss. What's a good date/time for the telecon? What are the time zone restrictions (i.e. where are all of you located)? Jeff At 03:43 AM 1/31/2008, Supalov, Alexander wrote: >Dear Edric, > >Thank you. I accepted all changes and updated the document slightly. >Note that I added version number to the file name to keep track of draft >editions. Please use this document for further contributions if you can. > >Now, to your points. The idea of a common compatibility "outlet" may I >think work well in practice, but this would be 2nd best solution if you >ask me. We should keep this option in mind as plan B (in fact, this >would be a standardized morph layer interface - a chance to save some >work downstream by reusing one of the existing morph packages). I'd >rather go for plan A first - agreeing on a "real" common interface if >possible. > >That ABI cannot cover the practical side of the matter is no problem if >one puts this into perspective: ABI is just another step on the way to >MPI maturity. Agreeing on functionality may come next if the ABI bet >pans out. > >Best regards. > >Alexander > >-- >Dr Alexander Supalov >Intel GmbH >Hermuelheimer Strasse 8a >50321 Bruehl, Germany >Phone: +49 2232 209034 >Mobile: +49 173 511 8735 >Fax: +49 2232 209029 > > >-----Original Message----- >From: Edric Ellis [mailto:Edric.Ellis_at_[hidden]] >Sent: Thursday, January 31, 2008 11:28 AM >To: Supalov, Alexander; Narasimhan, Kannan; Jeff Brown; Erez Haba; >Christian.Bell_at_[hidden]; Solt, David George >Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; >rlgraham_at_[hidden] >Subject: RE: ABI Working Group > >Hi Alexander, > >Thanks for that - there's lots of good stuff in there. I've added a few >things, and there are a couple more that I'm not entirely sure how best >to include, or perhaps they're already covered elsewhere: > >* It's possible to write an application that can compile successfully >with multiple MPI implementations, but works correctly with only one. >This issue is not intended to be addressed by the ABI as it is present >even with the current API. > >* In my mind, we could describe the ABI as effectively another language >binding. This would mean that MPI implementations were free to keep >their "native" mpi.h representation for situations where maximum >performance is required and recompilation is possible, and the "abi" >mpi.h library can be implemented using a morph layer or similar, and >this is used by applications that cannot be recompiled. > >Cheers, > >Edric. > > > -----Original Message----- > > From: Supalov, Alexander [mailto:alexander.supalov_at_[hidden]] > > Sent: Wednesday, January 30, 2008 10:41 PM > > To: Narasimhan, Kannan; Jeff Brown; Edric Ellis; Erez Haba; > > Christian.Bell_at_[hidden]; Solt, David George > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Hi everybody, > > > > Here comes the promised draft. Comments and updates are > > welcome. If you can, please use "Track Changes" in MS Word > > when contributing. > > > > Best regards. > > > > Alexander > > > > -- > > Dr Alexander Supalov > > Intel GmbH > > Hermuelheimer Strasse 8a > > 50321 Bruehl, Germany > > Phone: +49 2232 209034 > > Mobile: +49 173 511 8735 > > Fax: +49 2232 209029 > > > > > > -----Original Message----- > > From: Narasimhan, Kannan [mailto:kannan.narasimhan_at_[hidden]] > > Sent: Tuesday, January 29, 2008 10:50 PM > > To: Jeff Brown; Supalov, Alexander; Edric Ellis; Erez Haba; > > Christian.Bell_at_[hidden]; Solt, David George; Narasimhan, Kannan > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Adding David Solt to this Working Group (and email list). > > > > Thanx! > > Kannan > > > > -----Original Message----- > > From: Jeff Brown [mailto:jeffb_at_[hidden]] > > Sent: Tuesday, January 29, 2008 3:41 PM > > To: Supalov, Alexander; Edric Ellis; Erez Haba; Narasimhan, > > Kannan; Christian.Bell_at_[hidden] > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Let's see what we can get done by email, then set up a > > telecon for mid February. I have a couple of questions for the group: > > 1. what is the high level goal of this WG? > > > > should be covered in the intro to the proposal - Alexander to draft > > > > 2. what do we want to accomplish by the next Chicago meeting? > > > > have a fairly well thought out proposal out there to present > > to the larger group > > > > At 12:34 PM 1/29/2008, Supalov, Alexander wrote: > > >Hi, > > > > > >Upon creation of the email list and some pause, I would suggest to > > >organize a kickoff telecon with all who subscribe to the > > list by then. > > >Waiting till the next Forum meeting is also an option unless we're > > >under pressure to report out earlier to stay afloat. > > > > > >As for the contents, I'd first clearly identify - for us and for the > > >future readers/voters - what this proposal is about, and > > what is not in > > > > >its scope. Here, the earlier contributions may help to > > introduce some > > >co-ordinate system and select a patch we can reasonably hope to > > address. > > >I can sketch this intro up in the coming days. > > > > that would be great! > > > > > > >Then we have to select some procedure for editing the proposal, sit > > >down and write it. > > > > Let's see if we can draft a proposal prior to the telecon > > then send out to the larger group for review prior to the > > Chicago meeting. > > > > 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. --------------------------------------------------------------------- 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. From alexander.supalov at [hidden] Fri Feb 8 12:18:46 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 8 Feb 2008 18:18:46 -0000 Subject: [Mpi3-abi] ABI Working Group In-Reply-To: <5ECAB1304A8B5B4CB3F9D6C01E4E21A20104643C@swsmsx413.ger.corp.intel.com> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A20106D08B@swsmsx413.ger.corp.intel.com> Resending. -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Thursday, February 07, 2008 9:08 PM To: Jeff Brown; Edric Ellis; Narasimhan, Kannan; Erez Haba; Christian.Bell_at_[hidden]; Solt, David George; sameer Shende Cc: ddd_at_[hidden]; mpi3-abi_at_[hidden]; Nathan DeBardeleben Subject: Re: [Mpi3-abi] ABI Working Group Hi everybody, I've just uploaded an updated proposal version 0.3 to the ABI Wiki page (see http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage). Best regards. Alexander -----Original Message----- From: Jeff Brown [mailto:jeffb_at_[hidden]] Sent: Thursday, February 07, 2008 7:17 PM To: Supalov, Alexander; Edric Ellis; Narasimhan, Kannan; Erez Haba; Christian.Bell_at_[hidden]; Solt, David George; sameer Shende Cc: Nathan DeBardeleben; ddd_at_[hidden]; jeffb_at_[hidden] Subject: RE: ABI Working Group all, Let's start using the ABI WG email list so that the discussions will be archived, etc. To subscribe, link to: http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi Rich is encouraging all the working groups to have a mid term telecon some time within the next couple of weeks. I think we should do that as well. In preparation for the telecon, let's do some work on the draft proposal Alexander kicked off then discuss. What's a good date/time for the telecon? What are the time zone restrictions (i.e. where are all of you located)? Jeff At 03:43 AM 1/31/2008, Supalov, Alexander wrote: >Dear Edric, > >Thank you. I accepted all changes and updated the document slightly. >Note that I added version number to the file name to keep track of draft >editions. Please use this document for further contributions if you can. > >Now, to your points. The idea of a common compatibility "outlet" may I >think work well in practice, but this would be 2nd best solution if you >ask me. We should keep this option in mind as plan B (in fact, this >would be a standardized morph layer interface - a chance to save some >work downstream by reusing one of the existing morph packages). I'd >rather go for plan A first - agreeing on a "real" common interface if >possible. > >That ABI cannot cover the practical side of the matter is no problem if >one puts this into perspective: ABI is just another step on the way to >MPI maturity. Agreeing on functionality may come next if the ABI bet >pans out. > >Best regards. > >Alexander > >-- >Dr Alexander Supalov >Intel GmbH >Hermuelheimer Strasse 8a >50321 Bruehl, Germany >Phone: +49 2232 209034 >Mobile: +49 173 511 8735 >Fax: +49 2232 209029 > > >-----Original Message----- >From: Edric Ellis [mailto:Edric.Ellis_at_[hidden]] >Sent: Thursday, January 31, 2008 11:28 AM >To: Supalov, Alexander; Narasimhan, Kannan; Jeff Brown; Erez Haba; >Christian.Bell_at_[hidden]; Solt, David George >Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; >rlgraham_at_[hidden] >Subject: RE: ABI Working Group > >Hi Alexander, > >Thanks for that - there's lots of good stuff in there. I've added a few >things, and there are a couple more that I'm not entirely sure how best >to include, or perhaps they're already covered elsewhere: > >* It's possible to write an application that can compile successfully >with multiple MPI implementations, but works correctly with only one. >This issue is not intended to be addressed by the ABI as it is present >even with the current API. > >* In my mind, we could describe the ABI as effectively another language >binding. This would mean that MPI implementations were free to keep >their "native" mpi.h representation for situations where maximum >performance is required and recompilation is possible, and the "abi" >mpi.h library can be implemented using a morph layer or similar, and >this is used by applications that cannot be recompiled. > >Cheers, > >Edric. > > > -----Original Message----- > > From: Supalov, Alexander [mailto:alexander.supalov_at_[hidden]] > > Sent: Wednesday, January 30, 2008 10:41 PM > > To: Narasimhan, Kannan; Jeff Brown; Edric Ellis; Erez Haba; > > Christian.Bell_at_[hidden]; Solt, David George > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Hi everybody, > > > > Here comes the promised draft. Comments and updates are > > welcome. If you can, please use "Track Changes" in MS Word > > when contributing. > > > > Best regards. > > > > Alexander > > > > -- > > Dr Alexander Supalov > > Intel GmbH > > Hermuelheimer Strasse 8a > > 50321 Bruehl, Germany > > Phone: +49 2232 209034 > > Mobile: +49 173 511 8735 > > Fax: +49 2232 209029 > > > > > > -----Original Message----- > > From: Narasimhan, Kannan [mailto:kannan.narasimhan_at_[hidden]] > > Sent: Tuesday, January 29, 2008 10:50 PM > > To: Jeff Brown; Supalov, Alexander; Edric Ellis; Erez Haba; > > Christian.Bell_at_[hidden]; Solt, David George; Narasimhan, Kannan > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Adding David Solt to this Working Group (and email list). > > > > Thanx! > > Kannan > > > > -----Original Message----- > > From: Jeff Brown [mailto:jeffb_at_[hidden]] > > Sent: Tuesday, January 29, 2008 3:41 PM > > To: Supalov, Alexander; Edric Ellis; Erez Haba; Narasimhan, > > Kannan; Christian.Bell_at_[hidden] > > Cc: craig Rasmussen; Nathan DeBardeleben; ddd_at_[hidden]; > > rlgraham_at_[hidden] > > Subject: RE: ABI Working Group > > > > Let's see what we can get done by email, then set up a > > telecon for mid February. I have a couple of questions for the group: > > 1. what is the high level goal of this WG? > > > > should be covered in the intro to the proposal - Alexander to draft > > > > 2. what do we want to accomplish by the next Chicago meeting? > > > > have a fairly well thought out proposal out there to present > > to the larger group > > > > At 12:34 PM 1/29/2008, Supalov, Alexander wrote: > > >Hi, > > > > > >Upon creation of the email list and some pause, I would suggest to > > >organize a kickoff telecon with all who subscribe to the > > list by then. > > >Waiting till the next Forum meeting is also an option unless we're > > >under pressure to report out earlier to stay afloat. > > > > > >As for the contents, I'd first clearly identify - for us and for the > > >future readers/voters - what this proposal is about, and > > what is not in > > > > >its scope. Here, the earlier contributions may help to > > introduce some > > >co-ordinate system and select a patch we can reasonably hope to > > address. > > >I can sketch this intro up in the coming days. > > > > that would be great! > > > > > > >Then we have to select some procedure for editing the proposal, sit > > >down and write it. > > > > Let's see if we can draft a proposal prior to the telecon > > then send out to the larger group for review prior to the > > Chicago meeting. > > > > 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. --------------------------------------------------------------------- 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. _______________________________________________ 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. From jeffb at [hidden] Wed Feb 13 11:17:46 2008 From: jeffb at [hidden] (Jeff Brown) Date: Wed, 13 Feb 2008 10:17:46 -0700 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <5ECAB1304A8B5B4CB3F9D6C01E4E21A20104643C@swsmsx413.ger.cor p.intel.com> Message-ID: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> all, I'd like to set up the ABI WG telecon. Here's some times to choose from. Please let me know your preference and I'll set it up and send out the number. Wednesday February 20, 8:00 am PST, 17:00 CET Thursday February 21, 8:00 am PST, 17:00 CET Friday February 22, 8:00 am PST, 17:00 CET We can schedule a follow-up telecon the next week if necessary. Some items to address in the telecon (feel free to add to the list): - what are we trying to accomplish? (lets make sure we are all on the same page) - what do we mean by an "ABI"? (set the scope for our effort) - status of the proposal document - what do we want to have done by the March meeting? Let's all take some time reviewing the document Alexander posted to http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage Jeff From alexander.supalov at [hidden] Wed Feb 13 11:48:01 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Wed, 13 Feb 2008 17:48:01 -0000 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A201095C7E@swsmsx413.ger.corp.intel.com> Hi, Thanks. I can take Wednesday. Thursday is plan B. Friday is closed. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Wednesday, February 13, 2008 6:18 PM To: mpi3-abi_at_[hidden] Cc: ddd_at_[hidden]; ndebard_at_[hidden] Subject: [Mpi3-abi] ABI Working Group telecon all, I'd like to set up the ABI WG telecon. Here's some times to choose from. Please let me know your preference and I'll set it up and send out the number. Wednesday February 20, 8:00 am PST, 17:00 CET Thursday February 21, 8:00 am PST, 17:00 CET Friday February 22, 8:00 am PST, 17:00 CET We can schedule a follow-up telecon the next week if necessary. Some items to address in the telecon (feel free to add to the list): - what are we trying to accomplish? (lets make sure we are all on the same page) - what do we mean by an "ABI"? (set the scope for our effort) - status of the proposal document - what do we want to have done by the March meeting? Let's all take some time reviewing the document Alexander posted to http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage Jeff _______________________________________________ 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. From jsquyres at [hidden] Wed Feb 13 12:07:06 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 13 Feb 2008 13:07:06 -0500 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> Message-ID: Wednesday (all day) is unfortunately no good for me; Thursday or Friday works. On Feb 13, 2008, at 12:17 PM, Jeff Brown wrote: > all, > > I'd like to set up the ABI WG telecon. Here's some times to choose > from. Please let me know your preference and I'll set it up and send > out the number. > > Wednesday February 20, 8:00 am PST, 17:00 CET > Thursday February 21, 8:00 am PST, 17:00 CET > Friday February 22, 8:00 am PST, 17:00 CET > > We can schedule a follow-up telecon the next week if necessary. > > Some items to address in the telecon (feel free to add to the list): > - what are we trying to accomplish? (lets make sure we are all on the > same page) > - what do we mean by an "ABI"? (set the scope for our effort) > - status of the proposal document > - what do we want to have done by the March meeting? > > Let's all take some time reviewing the document Alexander posted to > http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage > > Jeff > > > _______________________________________________ > Mpi3-abi mailing list > Mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi -- Jeff Squyres Cisco Systems From kannan.narasimhan at [hidden] Wed Feb 13 12:11:51 2008 From: kannan.narasimhan at [hidden] (Narasimhan, Kannan) Date: Wed, 13 Feb 2008 18:11:51 +0000 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> Message-ID: I'm unavailable on Wednesday. Thursday or Friday works for me. Thanx! Kannan -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Wednesday, February 13, 2008 11:18 AM To: mpi3-abi_at_[hidden] Cc: ddd_at_[hidden]; ndebard_at_[hidden] Subject: [Mpi3-abi] ABI Working Group telecon all, I'd like to set up the ABI WG telecon. Here's some times to choose from. Please let me know your preference and I'll set it up and send out the number. Wednesday February 20, 8:00 am PST, 17:00 CET Thursday February 21, 8:00 am PST, 17:00 CET Friday February 22, 8:00 am PST, 17:00 CET We can schedule a follow-up telecon the next week if necessary. Some items to address in the telecon (feel free to add to the list): - what are we trying to accomplish? (lets make sure we are all on the same page) - what do we mean by an "ABI"? (set the scope for our effort) - status of the proposal document - what do we want to have done by the March meeting? Let's all take some time reviewing the document Alexander posted to http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage Jeff _______________________________________________ Mpi3-abi mailing list Mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi From Edric.Ellis at [hidden] Thu Feb 14 01:59:00 2008 From: Edric.Ellis at [hidden] (Edric Ellis) Date: Thu, 14 Feb 2008 07:59:00 -0000 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> Message-ID: Wednesday or Thursday would be best for me. Cheers, Edric. > -----Original Message----- > From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi- > bounces_at_[hidden]] On Behalf Of Jeff Brown > Sent: Wednesday, February 13, 2008 5:18 PM > To: mpi3-abi_at_[hidden] > Cc: ddd_at_[hidden]; ndebard_at_[hidden] > Subject: [Mpi3-abi] ABI Working Group telecon > > all, > > I'd like to set up the ABI WG telecon. Here's some times to choose > from. Please let me know your preference and I'll set it up and send > out the number. > > Wednesday February 20, 8:00 am PST, 17:00 CET > Thursday February 21, 8:00 am PST, 17:00 CET > Friday February 22, 8:00 am PST, 17:00 CET > > We can schedule a follow-up telecon the next week if necessary. > > Some items to address in the telecon (feel free to add to the list): > - what are we trying to accomplish? (lets make sure we are all on the > same page) > - what do we mean by an "ABI"? (set the scope for our effort) > - status of the proposal document > - what do we want to have done by the March meeting? > > Let's all take some time reviewing the document Alexander posted to > http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage > > Jeff > > > _______________________________________________ > Mpi3-abi mailing list > Mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi From erezh at [hidden] Thu Feb 14 11:42:55 2008 From: erezh at [hidden] (Erez Haba) Date: Thu, 14 Feb 2008 09:42:55 -0800 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080213094438.02b33690@ccs-mail.lanl.gov> Message-ID: <6B68D01C00C9994A8E150183E62A119E6F9D511939@NA-EXMSG-C105.redmond.corp.microsoft.com> I can do any day; however 8am PST does not work for me; 9am would be good. -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Wednesday, February 13, 2008 9:18 AM To: mpi3-abi_at_[hidden] Cc: ddd_at_[hidden]; ndebard_at_[hidden] Subject: [Mpi3-abi] ABI Working Group telecon all, I'd like to set up the ABI WG telecon. Here's some times to choose from. Please let me know your preference and I'll set it up and send out the number. Wednesday February 20, 8:00 am PST, 17:00 CET Thursday February 21, 8:00 am PST, 17:00 CET Friday February 22, 8:00 am PST, 17:00 CET We can schedule a follow-up telecon the next week if necessary. Some items to address in the telecon (feel free to add to the list): - what are we trying to accomplish? (lets make sure we are all on the same page) - what do we mean by an "ABI"? (set the scope for our effort) - status of the proposal document - what do we want to have done by the March meeting? Let's all take some time reviewing the document Alexander posted to http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage Jeff _______________________________________________ Mpi3-abi mailing list Mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi From jeffb at [hidden] Thu Feb 14 13:18:43 2008 From: jeffb at [hidden] (Jeff Brown) Date: Thu, 14 Feb 2008 12:18:43 -0700 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6B68D01C00C9994A8E150183E62A119E6F9D511939@NA-EXMSG-C105.r edmond.corp.microsoft.com> Message-ID: <6.2.3.4.2.20080214121824.02b3eed0@ccs-mail.lanl.gov> we'll see if that works for Alexander on his end At 10:42 AM 2/14/2008, you wrote: >I can do any day; however 8am PST does not work for me; 9am would be good. > >-----Original Message----- >From: mpi3-abi-bounces_at_[hidden] >[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown >Sent: Wednesday, February 13, 2008 9:18 AM >To: mpi3-abi_at_[hidden] >Cc: ddd_at_[hidden]; ndebard_at_[hidden] >Subject: [Mpi3-abi] ABI Working Group telecon > >all, > >I'd like to set up the ABI WG telecon. Here's some times to choose >from. Please let me know your preference and I'll set it up and send >out the number. > >Wednesday February 20, 8:00 am PST, 17:00 CET >Thursday February 21, 8:00 am PST, 17:00 CET >Friday February 22, 8:00 am PST, 17:00 CET > >We can schedule a follow-up telecon the next week if necessary. > >Some items to address in the telecon (feel free to add to the list): >- what are we trying to accomplish? (lets make sure we are all on the >same page) >- what do we mean by an "ABI"? (set the scope for our effort) >- status of the proposal document >- what do we want to have done by the March meeting? > >Let's all take some time reviewing the document Alexander posted to >http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage > >Jeff > > >_______________________________________________ >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 From alexander.supalov at [hidden] Thu Feb 14 23:51:42 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 15 Feb 2008 05:51:42 -0000 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080214121824.02b3eed0@ccs-mail.lanl.gov> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A2010BCAEA@swsmsx413.ger.corp.intel.com> Hi, Thanks. 9 am PST is best for Wednesday or Thursday in my case. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Thursday, February 14, 2008 8:19 PM To: mpi3-abi_at_[hidden] Subject: Re: [Mpi3-abi] ABI Working Group telecon we'll see if that works for Alexander on his end At 10:42 AM 2/14/2008, you wrote: >I can do any day; however 8am PST does not work for me; 9am would be good. > >-----Original Message----- >From: mpi3-abi-bounces_at_[hidden] >[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown >Sent: Wednesday, February 13, 2008 9:18 AM >To: mpi3-abi_at_[hidden] >Cc: ddd_at_[hidden]; ndebard_at_[hidden] >Subject: [Mpi3-abi] ABI Working Group telecon > >all, > >I'd like to set up the ABI WG telecon. Here's some times to choose >from. Please let me know your preference and I'll set it up and send >out the number. > >Wednesday February 20, 8:00 am PST, 17:00 CET >Thursday February 21, 8:00 am PST, 17:00 CET >Friday February 22, 8:00 am PST, 17:00 CET > >We can schedule a follow-up telecon the next week if necessary. > >Some items to address in the telecon (feel free to add to the list): >- what are we trying to accomplish? (lets make sure we are all on the >same page) >- what do we mean by an "ABI"? (set the scope for our effort) >- status of the proposal document >- what do we want to have done by the March meeting? > >Let's all take some time reviewing the document Alexander posted to >http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage > >Jeff > > >_______________________________________________ >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 --------------------------------------------------------------------- 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. From jeffb at [hidden] Tue Feb 19 09:30:26 2008 From: jeffb at [hidden] (Jeff Brown) Date: Tue, 19 Feb 2008 08:30:26 -0700 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <5ECAB1304A8B5B4CB3F9D6C01E4E21A2010BCAEA@swsmsx413.ger.cor p.intel.com> Message-ID: <6.2.3.4.2.20080219082539.02b3d010@ccs-mail.lanl.gov> all, Thursday February 21, 9:00 PST (18:00 CET) appears to work best for all concerned. I'll set up the telecon and send out the number. As this is the first meeting for this group, we will start out fairly high level to ensure we are all on the same page with common objectives, etc. Please send me any specific agenda items you would like to discuss. Jeff * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Tue Feb 19 10:31:23 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 19 Feb 2008 11:31:23 -0500 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080219082539.02b3d010@ccs-mail.lanl.gov> Message-ID: Thanks Jeff. One item I'd like to discuss is Alexander's proposal -- he specifically stated that it was for theoretical link compatibility. Can we review the goals for this specific promise / level of ABI on the call? (I suspect it can be discussed far quicker on the teleconf than iterating through a dozen e-mails). Thanks. On Feb 19, 2008, at 10:30 AM, Jeff Brown wrote: > all, > > Thursday February 21, 9:00 PST (18:00 CET) appears to work best for > all concerned. > > I'll set up the telecon and send out the number. > > As this is the first meeting for this group, we will start out > fairly high level to ensure we are all on the same page with common > objectives, etc. > > Please send me any specific agenda items you would like to discuss. > > Jeff > _______________________________________________ > Mpi3-abi mailing list > Mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi -- Jeff Squyres Cisco Systems From jeffb at [hidden] Tue Feb 19 10:38:01 2008 From: jeffb at [hidden] (Jeff Brown) Date: Tue, 19 Feb 2008 09:38:01 -0700 Subject: [Mpi3-abi] Fwd: Conference call confirmation "MPI Forum ABI working group meeting" Message-ID: <6.2.3.4.2.20080219093613.02c03300@ccs-mail.lanl.gov> FYI - here's the telecon info I'll send out an agenda (please send requested topics). Jeff >X-Sieve: CMU Sieve 2.2 >X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 >Date: Tue, 19 Feb 2008 08:50:36 -0700 >To: Jeff Brown ,vtc_at_[hidden] >From: Shelley Olguin >Subject: Conference call confirmation "MPI Forum ABI working group > meeting" >X-CTN-5-MailScanner-Information: Please see >http://network.lanl.gov/email/virus-scan.php >X-CTN-5-MailScanner: Found to be clean >X-CTN-5-MailScanner-From: shel_at_[hidden] >X-Spam-Status: No > >Hi Jeff, > >I have set this up per your request below. The dial in numbers are >as follows: > >606-1000 local 888-290-4229 toll free > >Should you have any concerns, please call 5-2254 or 5-3000. > >Shelley > >At 08:41 AM 2/19/2008, Jeff Brown wrote: >>I need a telecon set up. >> >> title: MPI Forum ABI working group meeting >> date: Thursday February 21, 10:00 MST >> requester: Jeff Brown, CCS-1 >> Z#: 098729 >># of participants: 15 >> cost code: 3T010A/JAEC CPTP-0000 >> >>thanks! >> >>Jeff Brown >-- >Shelley A. Olguin >CTN-4 Computing, Telecommunications, & Networking >Office Phone: 505.665.2254 >Pager: 505.664.1649 >Fax: 505.665.1634 >Web: http://int.lanl.gov/orgs/ctn/ctn4/vtc/index1.shtml >Email: shel_at_[hidden] > > > * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffb at [hidden] Tue Feb 19 10:49:28 2008 From: jeffb at [hidden] (Jeff Brown) Date: Tue, 19 Feb 2008 09:49:28 -0700 Subject: [Mpi3-abi] Fwd: Conference call confirmation "MPI Forum ABI working group meeting" In-Reply-To: <6.2.3.4.2.20080219093613.02c03300@ccs-mail.lanl.gov> Message-ID: <6.2.3.4.2.20080219094642.02c0c638@ccs-mail.lanl.gov> To hopefully avoid confusion, please note that the time for the telecon is: 9:00 PST 10:00 MST 18:00 CET Jeff At 09:38 AM 2/19/2008, Jeff Brown wrote: >FYI - here's the telecon info > >I'll send out an agenda (please send requested topics). > >Jeff > >>X-Sieve: CMU Sieve 2.2 >>X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 >>Date: Tue, 19 Feb 2008 08:50:36 -0700 >>To: Jeff Brown ,vtc_at_[hidden] >>From: Shelley Olguin >>Subject: Conference call confirmation "MPI Forum ABI working group >> meeting" >>X-CTN-5-MailScanner-Information: Please see >>http://network.lanl.gov/email/virus-scan.php >>X-CTN-5-MailScanner: Found to be clean >>X-CTN-5-MailScanner-From: shel_at_[hidden] >>X-Spam-Status: No >> >>Hi Jeff, >> >>I have set this up per your request below. The dial in numbers are >>as follows: >> >>606-1000 local 888-290-4229 toll free >> >>Should you have any concerns, please call 5-2254 or 5-3000. >> >>Shelley >> >>At 08:41 AM 2/19/2008, Jeff Brown wrote: >>>I need a telecon set up. >>> >>> title: MPI Forum ABI working group meeting >>> date: Thursday February 21, 10:00 MST >>> requester: Jeff Brown, CCS-1 >>> Z#: 098729 >>># of participants: 15 >>> cost code: 3T010A/JAEC CPTP-0000 >>> >>>thanks! >>> >>>Jeff Brown >>-- >>Shelley A. Olguin >>CTN-4 Computing, Telecommunications, & Networking >>Office Phone: 505.665.2254 >>Pager: 505.664.1649 >>Fax: 505.665.1634 >>Web: http://int.lanl.gov/orgs/ctn/ctn4/vtc/index1.shtml >>Email: shel_at_[hidden] >> >> * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffb at [hidden] Tue Feb 19 11:04:15 2008 From: jeffb at [hidden] (Jeff Brown) Date: Tue, 19 Feb 2008 10:04:15 -0700 Subject: [Mpi3-abi] Fwd: Conference call confirmation "MPI Forum ABI working group meeting" In-Reply-To: <6.2.3.4.2.20080219094642.02c0c638@ccs-mail.lanl.gov> Message-ID: <6.2.3.4.2.20080219095852.02ce4d70@ccs-mail.lanl.gov> One more thing ... We have no international toll free number. Folks calling in from outside the U.S. need to dial into the "local" number and would have to pay for the international call (sorry). The "local" number is (505) 606-1000. Callers from inside the U.S. can dial the toll free number: (888) 290-4229. Do I have a volunteer to take notes? Jeff At 09:49 AM 2/19/2008, Jeff Brown wrote: >To hopefully avoid confusion, please note that the time for the telecon is: > > 9:00 PST >10:00 MST >18:00 CET > >Jeff > >At 09:38 AM 2/19/2008, Jeff Brown wrote: >>FYI - here's the telecon info >> >>I'll send out an agenda (please send requested topics). >> >>Jeff >> >>>X-Sieve: CMU Sieve 2.2 >>>X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 >>>Date: Tue, 19 Feb 2008 08:50:36 -0700 >>>To: Jeff Brown ,vtc_at_[hidden] >>>From: Shelley Olguin >>>Subject: Conference call confirmation "MPI Forum ABI working group >>> meeting" >>>X-CTN-5-MailScanner-Information: Please see >>>http://network.lanl.gov/email/virus-scan.php >>>X-CTN-5-MailScanner: Found to be clean >>>X-CTN-5-MailScanner-From: shel_at_[hidden] >>>X-Spam-Status: No >>> >>>Hi Jeff, >>> >>>I have set this up per your request below. The dial in numbers >>>are as follows: >>> >>>606-1000 local 888-290-4229 toll free >>> >>>Should you have any concerns, please call 5-2254 or 5-3000. >>> >>>Shelley >>> >>>At 08:41 AM 2/19/2008, Jeff Brown wrote: >>>>I need a telecon set up. >>>> >>>> title: MPI Forum ABI working group meeting >>>> date: Thursday February 21, 10:00 MST >>>> requester: Jeff Brown, CCS-1 >>>> Z#: 098729 >>>># of participants: 15 >>>> cost code: 3T010A/JAEC CPTP-0000 >>>> >>>>thanks! >>>> >>>>Jeff Brown >>>-- >>>Shelley A. Olguin >>>CTN-4 Computing, Telecommunications, & Networking >>>Office Phone: 505.665.2254 >>>Pager: 505.664.1649 >>>Fax: 505.665.1634 >>>Web: http://int.lanl.gov/orgs/ctn/ctn4/vtc/index1.shtml >>>Email: shel_at_[hidden] >>> >_______________________________________________ >Mpi3-abi mailing list >Mpi3-abi_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi * -------------- next part -------------- An HTML attachment was scrubbed... URL: From erezh at [hidden] Tue Feb 19 22:37:34 2008 From: erezh at [hidden] (Erez Haba) Date: Tue, 19 Feb 2008 20:37:34 -0800 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6.2.3.4.2.20080219082539.02b3d010@ccs-mail.lanl.gov> Message-ID: <6B68D01C00C9994A8E150183E62A119E6FE42A248A@NA-EXMSG-C105.redmond.corp.microsoft.com> Do you have the call details? From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Tuesday, February 19, 2008 7:30 AM To: mpi3-abi_at_[hidden]; mpi3-abi_at_[hidden] Subject: Re: [Mpi3-abi] ABI Working Group telecon all, Thursday February 21, 9:00 PST (18:00 CET) appears to work best for all concerned. I'll set up the telecon and send out the number. As this is the first meeting for this group, we will start out fairly high level to ensure we are all on the same page with common objectives, etc. Please send me any specific agenda items you would like to discuss. Jeff * -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.supalov at [hidden] Wed Feb 20 02:09:26 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Wed, 20 Feb 2008 08:09:26 -0000 Subject: [Mpi3-abi] ABI Working Group telecon In-Reply-To: <6B68D01C00C9994A8E150183E62A119E6FE42A248A@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A2010E9E5D@swsmsx413.ger.corp.intel.com> +1 (505) 606-1000 local 888-290-4229 toll free title: MPI Forum ABI working group meeting date: Thursday February 21, 10:00 MST --------------------------------------------------------------------- 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. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffb at [hidden] Wed Feb 20 18:25:07 2008 From: jeffb at [hidden] (Jeff Brown) Date: Wed, 20 Feb 2008 17:25:07 -0700 Subject: [Mpi3-abi] Conference call confirmation "MPI Forum ABI working group meeting" In-Reply-To: <6.2.3.4.2.20080219095852.02ce4d70@ccs-mail.lanl.gov> Message-ID: <6.2.3.4.2.20080220171958.02bcda88@ccs-mail.lanl.gov> reminder - ABI WG conference call tomorrow morning (Thursday) at 10:00 A.M. MST rough agenda: - a round of introductions (and identify a note taker) - discuss our shared objectives - define the scope of our effort (what do we mean by an ABI) - review Alexander's proposal - discuss what we want to accomplish by the March meeting (add your topic here) Talk to you in the morning. Jeff At 10:04 AM 2/19/2008, Jeff Brown wrote: >One more thing ... > >We have no international toll free number. Folks calling in from >outside the U.S. need to dial into the "local" number and would have >to pay for the international call (sorry). The "local" number is >(505) 606-1000. > >Callers from inside the U.S. can dial the toll free number: (888) 290-4229. > >Do I have a volunteer to take notes? > >Jeff > >At 09:49 AM 2/19/2008, Jeff Brown wrote: >>To hopefully avoid confusion, please note that the time for the telecon is: >> >> 9:00 PST >>10:00 MST >>18:00 CET >> >>Jeff >> >>At 09:38 AM 2/19/2008, Jeff Brown wrote: >>>FYI - here's the telecon info >>> >>>I'll send out an agenda (please send requested topics). >>> >>>Jeff >>> >>>>X-Sieve: CMU Sieve 2.2 >>>>X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 >>>>Date: Tue, 19 Feb 2008 08:50:36 -0700 >>>>To: Jeff Brown ,vtc_at_[hidden] >>>>From: Shelley Olguin >>>>Subject: Conference call confirmation "MPI Forum ABI working group >>>> meeting" >>>>X-CTN-5-MailScanner-Information: Please see >>>>http://network.lanl.gov/email/virus-scan.php >>>>X-CTN-5-MailScanner: Found to be clean >>>>X-CTN-5-MailScanner-From: shel_at_[hidden] >>>>X-Spam-Status: No >>>> >>>>Hi Jeff, >>>> >>>>I have set this up per your request below. The dial in numbers >>>>are as follows: >>>> >>>>606-1000 local 888-290-4229 toll free >>>> >>>>Should you have any concerns, please call 5-2254 or 5-3000. >>>> >>>>Shelley >>>> >>>>At 08:41 AM 2/19/2008, Jeff Brown wrote: >>>>>I need a telecon set up. >>>>> >>>>> title: MPI Forum ABI working group meeting >>>>> date: Thursday February 21, 10:00 MST >>>>> requester: Jeff Brown, CCS-1 >>>>> Z#: 098729 >>>>># of participants: 15 >>>>> cost code: 3T010A/JAEC CPTP-0000 >>>>> >>>>>thanks! >>>>> >>>>>Jeff Brown >>>>-- >>>>Shelley A. Olguin >>>>CTN-4 Computing, Telecommunications, & Networking >>>>Office Phone: 505.665.2254 >>>>Pager: 505.664.1649 >>>>Fax: 505.665.1634 >>>>Web: http://int.lanl.gov/orgs/ctn/ctn4/vtc/index1.shtml >>>>Email: shel_at_[hidden] >>_______________________________________________ >>Mpi3-abi mailing list >>Mpi3-abi_at_[hidden] >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffb at [hidden] Thu Feb 21 10:36:53 2008 From: jeffb at [hidden] (Jeff Brown) Date: Thu, 21 Feb 2008 09:36:53 -0700 Subject: [Mpi3-abi] Fwd: questions to drive the telecon Message-ID: <6.2.3.4.2.20080221093559.02bd1658@ccs-mail.lanl.gov> all, I put together some questions/comments that can help drive the telecon this morning. Jeff >ABI WG telecon agenga/notes/questions > >- what is the motivation for this effort? > ISVs cannot distribute a single binary that includes MPI code > - must have either a translation layer or separate binaries for > each mpi implementation (and compiler?) > sites must maintain a separate "module" for every compiler/mpi > combination on the system > users must recompile for every compiler/mpi combination > >- what are we trying to accomplish? > app compiled with a "standard" mpi.h/mpif.h is compatible with > standard compliant mpi implementations compiled on that same platform > this would allow for run-time dynamic linking > does not address items external to the binary such as environment > variables and command line arguments > >- what do we mean by an "ABI" > >- comments on a translation layer > may be somewhat viable for an ISV, but not acceptable for a user site > just another layer of software to maintain > may or may not track what we have on site > >- what work is involved? > "standard" mpi.h > anything else? > >- how do we integrate into the standard? > >- what is the process to extend "standard" mpi.h content? > >- what's the proposal process? > >- what do we present at the March meeting? > > From erezh at [hidden] Thu Feb 21 10:47:35 2008 From: erezh at [hidden] (Erez Haba) Date: Thu, 21 Feb 2008 08:47:35 -0800 Subject: [Mpi3-abi] Fwd: questions to drive the telecon In-Reply-To: <6.2.3.4.2.20080221093559.02bd1658@ccs-mail.lanl.gov> Message-ID: <6B68D01C00C9994A8E150183E62A119E6FE4653CF8@NA-EXMSG-C105.redmond.corp.microsoft.com> Thanks Jeff, these are very good questions!! I would start by us defining the "user" terminology, to put us on the same page. e.g., the user is it the developer using MPI (aka ISV) is it the end-user running the application... etc. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Thursday, February 21, 2008 8:37 AM To: mpi3-abi_at_[hidden] Subject: [Mpi3-abi] Fwd: questions to drive the telecon all, I put together some questions/comments that can help drive the telecon this morning. Jeff >ABI WG telecon agenga/notes/questions > >- what is the motivation for this effort? > ISVs cannot distribute a single binary that includes MPI code > - must have either a translation layer or separate binaries for > each mpi implementation (and compiler?) > sites must maintain a separate "module" for every compiler/mpi > combination on the system > users must recompile for every compiler/mpi combination > >- what are we trying to accomplish? > app compiled with a "standard" mpi.h/mpif.h is compatible with > standard compliant mpi implementations compiled on that same platform > this would allow for run-time dynamic linking > does not address items external to the binary such as environment > variables and command line arguments > >- what do we mean by an "ABI" > >- comments on a translation layer > may be somewhat viable for an ISV, but not acceptable for a user site > just another layer of software to maintain > may or may not track what we have on site > >- what work is involved? > "standard" mpi.h > anything else? > >- how do we integrate into the standard? > >- what is the process to extend "standard" mpi.h content? > >- what's the proposal process? > >- what do we present at the March meeting? > > _______________________________________________ Mpi3-abi mailing list Mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi From david.solt at [hidden] Thu Feb 21 17:33:16 2008 From: david.solt at [hidden] (Solt, David George) Date: Thu, 21 Feb 2008 23:33:16 +0000 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting Message-ID: 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). From alexander.supalov at [hidden] Thu Feb 21 22:43:51 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 22 Feb 2008 04:43:51 -0000 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A2011113C6@swsmsx413.ger.corp.intel.com> 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. From alexander.supalov at [hidden] Thu Feb 21 23:46:53 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 22 Feb 2008 05:46:53 -0000 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A2011113CB@swsmsx413.ger.corp.intel.com> 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. From jeffb at [hidden] Fri Feb 22 11:14:34 2008 From: jeffb at [hidden] (Jeff Brown) Date: Fri, 22 Feb 2008 10:14:34 -0700 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: Message-ID: <6.2.3.4.2.20080222095907.02bea5b0@ccs-mail.lanl.gov> 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 From david.solt at [hidden] Tue Feb 26 10:14:32 2008 From: david.solt at [hidden] (Solt, David George) Date: Tue, 26 Feb 2008 16:14:32 +0000 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: <6.2.3.4.2.20080222095907.02bea5b0@ccs-mail.lanl.gov> Message-ID: 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 From jeffb at [hidden] Tue Feb 26 10:53:33 2008 From: jeffb at [hidden] (Jeff Brown) Date: Tue, 26 Feb 2008 09:53:33 -0700 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: Message-ID: <6.2.3.4.2.20080226095243.094aba70@ccs-mail.lanl.gov> 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 From alexander.supalov at [hidden] Fri Feb 29 05:54:01 2008 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 29 Feb 2008 11:54:01 -0000 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: <6.2.3.4.2.20080226095243.094aba70@ccs-mail.lanl.gov> Message-ID: <5ECAB1304A8B5B4CB3F9D6C01E4E21A201197290@swsmsx413.ger.corp.intel.com> Hi, Some math libraries are indeed built for several MPIs (think Intel Math Kernel Libraries, for examples - they include Scalapack, too). Maintaining backward compatibility is a must for industrial implementations, thanks for bringing this up. I hope the ABI design will alleviate the issues you addressed as much as possible. If not, we're talking about MPI-3, and recompilation may become a viable option at some point. Minding the IMPI story, you're right, we should be united in offering the standard ABI to make it fly. Once ISVs and end users see compelling value, they will convert sooner or later, and help each other in the process. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Tuesday, February 26, 2008 5:54 PM To: mpi3-abi_at_[hidden] Subject: Re: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting 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 _______________________________________________ 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. From erezh at [hidden] Fri Feb 29 11:12:18 2008 From: erezh at [hidden] (Erez Haba) Date: Fri, 29 Feb 2008 09:12:18 -0800 Subject: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting In-Reply-To: <5ECAB1304A8B5B4CB3F9D6C01E4E21A201197290@swsmsx413.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E6FE481EBFF@NA-EXMSG-C105.redmond.corp.microsoft.com> Hi all, I don't think we can avoid breaking some MPI implementations backward compatibility. However, that should be a onetime thing and going forward the ABI should continue and keep backward compatibility. As suggested before there are solutions for the specific implementations, like providing and adaptation layer from their interface to the ABI interface or vice versa. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Friday, February 29, 2008 3:54 AM To: mpi3-abi_at_[hidden] Subject: Re: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting Hi, Some math libraries are indeed built for several MPIs (think Intel Math Kernel Libraries, for examples - they include Scalapack, too). Maintaining backward compatibility is a must for industrial implementations, thanks for bringing this up. I hope the ABI design will alleviate the issues you addressed as much as possible. If not, we're talking about MPI-3, and recompilation may become a viable option at some point. Minding the IMPI story, you're right, we should be united in offering the standard ABI to make it fly. Once ISVs and end users see compelling value, they will convert sooner or later, and help each other in the process. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Brown Sent: Tuesday, February 26, 2008 5:54 PM To: mpi3-abi_at_[hidden] Subject: Re: [Mpi3-abi] Minutes of MPI ABI working group 2/21/08 meeting 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 _______________________________________________ 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. _______________________________________________ Mpi3-abi mailing list Mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi