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

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 28 Apr '08

28 Apr '08

After speaking with Alexander, I updated the spreadsheet and assigned column owners (see attached comment in the column headings), and refined the MPICH columns a bit. Attached and uploaded to the wiki. Jeff > I added LAMPI (Los Alamos MPI) and documented the vendor > implementations that were mentioned that follow an existing > implementation. Uploaded to the wiki. > > See everyone at the meeting. > > Jeff > > At 06:38 PM 4/25/2008, Narasimhan, Kannan wrote: >>I've added HP-MPI data to the spread sheet, and uploaded it to the >>Wiki. I've focused on the Linux version of mpi.h (the Windows and >>HP-UX versions currently have minor differences, but we plan >>to normalize to the Linux version in future). >> >>-Kannan- >> >>-----Original Message----- >>From: mpi3-abi-bounces_at_[hidden] >>[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, >> Alexander >>Sent: Friday, April 25, 2008 7:32 AM >>To: MPI 3.0 ABI working group >>Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting >> >>Hi, >> >>The purpose of having as much input data as possible before deciding >>whether and how to proceed is to not miss a potentially important data >> point. >> >>In this vein, I'd love to see some MPICH1 and HP MPI data there. >>That, with the data already in the spreadsheet, would most likely >>cover 99% of the currently targeted platforms >> (IA32/Intel64/Linux/Windows). >> >>A split into several files would make sense if we had dozens of >>actively contributing members. At the moment we are blessed with but a >> few. >> >>Best regards. >> >>Alexander >> >>-----Original Message----- >>From: mpi3-abi-bounces_at_[hidden] >>[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres >>Sent: Friday, April 25, 2008 12:41 PM >>To: MPI 3.0 ABI working group >>Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting >> >>On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: >> >> > I've reviewed the current spreadsheet. Note that according to our >> > current observations, 64-bit Linux column covers Itanium Linux as >> > well, as far as the contents of the MPICH2 mpi.h is concerned. I take >> > this as an indication that we should not forget that ABI is more than >> > mpi.h, and that we should be very specific in the platform >> > description. >> > >> > Also, we might want to split Linux and Windows into different >> > subsheets. >> > Indeed, splitting into 32- and 64-bit might be helpful as well, as >> > soon as the table becomes densely populated. I think this is something >> > we should discuss when we see a joint ABI emerging. >> >>What is the goal for all of this analysis? I think we can already tell >> that: >> >>- many MPI implementations have different fixed values for the same >>MPI constants/etc. >>- some MPI implementations have run-time determined values (e.g., >>pointers) >>- some MPI implementations change values/types based on the compiler >>+platform that they are operating on >> >>Do we really need to make a comprehensive list of all MPI's on all >>compiler+platforms to see these trends? Is there specific data that >>would be gleaned from these vs. seeing a representative sample? >> >>(just trying to understand the purpose of the ever-expanding >>spreadsheet) >> >> > I have a process question here: how do we prevent multiple updates >> > running into each other, or overwriting each other accidentally? Is >> > there a check-in/out feature in Wiki, or should we introduce a manual >> > lock? Say, a file with a well known name to create before editing and >> > delete afterwards? The name of the creator would show who's holding >> > the lock. The modification date of the main file would show whether >> > the copy you're working with is still actual. >> >> >>How about creating separate spreadsheets, one for each MPI >>implementation? This would allow for more-or-less independent updates. >> >>At some point in the future (when most changes have been complete), >>they can be [re-]merged back into one spreadsheet. >> >>-- >>Jeff Squyres >>Cisco Systems >> >>_______________________________________________ >>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 >> >>_______________________________________________ >>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 > *

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 26 Apr '08

26 Apr '08

I added LAMPI (Los Alamos MPI) and documented the vendor implementations that were mentioned that follow an existing implementation. Uploaded to the wiki. See everyone at the meeting. Jeff At 06:38 PM 4/25/2008, Narasimhan, Kannan wrote: >I've added HP-MPI data to the spread sheet, and uploaded it to the >Wiki. I've focused on the Linux version of mpi.h (the Windows and >HP-UX versions currently have minor differences, but we plan >to normalize to the Linux version in future). > >-Kannan- > >-----Original Message----- >From: mpi3-abi-bounces_at_[hidden] >[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, Alexander >Sent: Friday, April 25, 2008 7:32 AM >To: MPI 3.0 ABI working group >Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting > >Hi, > >The purpose of having as much input data as possible before deciding >whether and how to proceed is to not miss a potentially important data point. > >In this vein, I'd love to see some MPICH1 and HP MPI data there. >That, with the data already in the spreadsheet, would most likely >cover 99% of the currently targeted platforms (IA32/Intel64/Linux/Windows). > >A split into several files would make sense if we had dozens of >actively contributing members. At the moment we are blessed with but a few. > >Best regards. > >Alexander > >-----Original Message----- >From: mpi3-abi-bounces_at_[hidden] >[mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres >Sent: Friday, April 25, 2008 12:41 PM >To: MPI 3.0 ABI working group >Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting > >On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: > > > I've reviewed the current spreadsheet. Note that according to our > > current observations, 64-bit Linux column covers Itanium Linux as > > well, as far as the contents of the MPICH2 mpi.h is concerned. I take > > this as an indication that we should not forget that ABI is more than > > mpi.h, and that we should be very specific in the platform > > description. > > > > Also, we might want to split Linux and Windows into different > > subsheets. > > Indeed, splitting into 32- and 64-bit might be helpful as well, as > > soon as the table becomes densely populated. I think this is something > > we should discuss when we see a joint ABI emerging. > >What is the goal for all of this analysis? I think we can already tell that: > >- many MPI implementations have different fixed values for the same >MPI constants/etc. >- some MPI implementations have run-time determined values (e.g., >pointers) >- some MPI implementations change values/types based on the compiler >+platform that they are operating on > >Do we really need to make a comprehensive list of all MPI's on all >compiler+platforms to see these trends? Is there specific data that >would be gleaned from these vs. seeing a representative sample? > >(just trying to understand the purpose of the ever-expanding >spreadsheet) > > > I have a process question here: how do we prevent multiple updates > > running into each other, or overwriting each other accidentally? Is > > there a check-in/out feature in Wiki, or should we introduce a manual > > lock? Say, a file with a well known name to create before editing and > > delete afterwards? The name of the creator would show who's holding > > the lock. The modification date of the main file would show whether > > the copy you're working with is still actual. > > >How about creating separate spreadsheets, one for each MPI >implementation? This would allow for more-or-less independent updates. > >At some point in the future (when most changes have been complete), >they can be [re-]merged back into one spreadsheet. > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >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 > >_______________________________________________ >mpi3-abi mailing list >mpi3-abi_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 26 Apr '08

26 Apr '08

Thanks. I took the liberty of removing the older document, so that we have one source for the MPICH addition we need to complete the rough picture. Who could take on that? -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Saturday, April 26, 2008 2:38 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting I've added HP-MPI data to the spread sheet, and uploaded it to the Wiki. I've focused on the Linux version of mpi.h (the Windows and HP-UX versions currently have minor differences, but we plan to normalize to the Linux version in future). -Kannan- -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Friday, April 25, 2008 7:32 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting Hi, The purpose of having as much input data as possible before deciding whether and how to proceed is to not miss a potentially important data point. In this vein, I'd love to see some MPICH1 and HP MPI data there. That, with the data already in the spreadsheet, would most likely cover 99% of the currently targeted platforms (IA32/Intel64/Linux/Windows). A split into several files would make sense if we had dozens of actively contributing members. At the moment we are blessed with but a few. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 12:41 PM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: > I've reviewed the current spreadsheet. Note that according to our > current observations, 64-bit Linux column covers Itanium Linux as > well, as far as the contents of the MPICH2 mpi.h is concerned. I take > this as an indication that we should not forget that ABI is more than > mpi.h, and that we should be very specific in the platform > description. > > Also, we might want to split Linux and Windows into different > subsheets. > Indeed, splitting into 32- and 64-bit might be helpful as well, as > soon as the table becomes densely populated. I think this is something > we should discuss when we see a joint ABI emerging. What is the goal for all of this analysis? I think we can already tell that: - many MPI implementations have different fixed values for the same MPI constants/etc. - some MPI implementations have run-time determined values (e.g., pointers) - some MPI implementations change values/types based on the compiler +platform that they are operating on Do we really need to make a comprehensive list of all MPI's on all compiler+platforms to see these trends? Is there specific data that would be gleaned from these vs. seeing a representative sample? (just trying to understand the purpose of the ever-expanding spreadsheet) > I have a process question here: how do we prevent multiple updates > running into each other, or overwriting each other accidentally? Is > there a check-in/out feature in Wiki, or should we introduce a manual > lock? Say, a file with a well known name to create before editing and > delete afterwards? The name of the creator would show who's holding > the lock. The modification date of the main file would show whether > the copy you're working with is still actual. How about creating separate spreadsheets, one for each MPI implementation? This would allow for more-or-less independent updates. At some point in the future (when most changes have been complete), they can be [re-]merged back into one spreadsheet. -- Jeff Squyres Cisco Systems _______________________________________________ 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 _______________________________________________ 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.

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

I've added HP-MPI data to the spread sheet, and uploaded it to the Wiki. I've focused on the Linux version of mpi.h (the Windows and HP-UX versions currently have minor differences, but we plan to normalize to the Linux version in future). -Kannan- -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Friday, April 25, 2008 7:32 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting Hi, The purpose of having as much input data as possible before deciding whether and how to proceed is to not miss a potentially important data point. In this vein, I'd love to see some MPICH1 and HP MPI data there. That, with the data already in the spreadsheet, would most likely cover 99% of the currently targeted platforms (IA32/Intel64/Linux/Windows). A split into several files would make sense if we had dozens of actively contributing members. At the moment we are blessed with but a few. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 12:41 PM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: > I've reviewed the current spreadsheet. Note that according to our > current observations, 64-bit Linux column covers Itanium Linux as > well, as far as the contents of the MPICH2 mpi.h is concerned. I take > this as an indication that we should not forget that ABI is more than > mpi.h, and that we should be very specific in the platform > description. > > Also, we might want to split Linux and Windows into different > subsheets. > Indeed, splitting into 32- and 64-bit might be helpful as well, as > soon as the table becomes densely populated. I think this is something > we should discuss when we see a joint ABI emerging. What is the goal for all of this analysis? I think we can already tell that: - many MPI implementations have different fixed values for the same MPI constants/etc. - some MPI implementations have run-time determined values (e.g., pointers) - some MPI implementations change values/types based on the compiler +platform that they are operating on Do we really need to make a comprehensive list of all MPI's on all compiler+platforms to see these trends? Is there specific data that would be gleaned from these vs. seeing a representative sample? (just trying to understand the purpose of the ever-expanding spreadsheet) > I have a process question here: how do we prevent multiple updates > running into each other, or overwriting each other accidentally? Is > there a check-in/out feature in Wiki, or should we introduce a manual > lock? Say, a file with a well known name to create before editing and > delete afterwards? The name of the creator would show who's holding > the lock. The modification date of the main file would show whether > the copy you're working with is still actual. How about creating separate spreadsheets, one for each MPI implementation? This would allow for more-or-less independent updates. At some point in the future (when most changes have been complete), they can be [re-]merged back into one spreadsheet. -- Jeff Squyres Cisco Systems _______________________________________________ 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

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

Hi, I've updated Jeff's file in the Wiki: some formatting, some typos fixed (in red), etc. Best regards. Alexander -----Original Message----- From: Supalov, Alexander Sent: Friday, April 25, 2008 8:12 PM To: 'MPI 3.0 ABI working group' Subject: RE: [Mpi3-abi] For the April MPI Forum Meeting Hi, The initial ABI proposal draft (see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/AbiWikiPage/MPI…) cites Bill Gropp's paper to introduce the MPI constant hierarchy basing on when the items are/should be defined according to the standard. We can use that hierarchy to split all ABI entities into groups. Here is the pertinent excerpt: - Compatible MPI data entities o Compile-time values § Used in declarations (MPI_MAX_ERROR_STRING, etc.) § Other (MPI_ANY_SOURCE, MPI_ERR_TRUNCATE, etc.) o Init-time constants (MPI_INT, etc.) o Opaque objects (MPI_Comm, MPI_Datatype, etc.) o Defined objects (MPI_Status) o Defined pointers (MPI_BOTTOM, MPI_STATUS_NULL, etc.) And while we're so focused on the mpi.h contents, I can't help reiterating that this is but a part of the ABI matter. The following is no less important for the whole thing to work: - Uniform approach to the macro implementation of certain functions (MPI_Wtime, MPI_Wtick, handle conversion calls, possibly others) - Similar calling convention o Argument order and size o Stack frame management policy o Return address storage and handling o Function call and return handling - Common linkage convention o Library file format o MPI library name o MPI library path resolution mechanism o System library dependency resolution Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Friday, April 25, 2008 6:01 PM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting I think that we need enough data to put the constants into classes of constants that are different from one implementation to the other (examples for a classes, are "handles", "datatype"). Once done, we'll be able to understand the differences in the different implementations (approach) and in the different platforms. This will enable us to come up with reasonable suggestion for the ABI constants. I think that putting the constants in different spreadsheet (split by os/cpu) is reasonable. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 7:04 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote: > The purpose of having as much input data as possible before deciding > whether and how to proceed is to not miss a potentially important data > point. > > In this vein, I'd love to see some MPICH1 and HP MPI data there. That, > with the data already in the spreadsheet, would most likely cover > 99% of > the currently targeted platforms (IA32/Intel64/Linux/Windows). I'm all for having enough data points. I was questioning how many we need -- it just looked like we we diverging into the "need dozens of datapoints" realm. If we're not, no problem. > A split into several files would make sense if we had dozens of > actively > contributing members. At the moment we are blessed with but a few. The wiki has no "lock" feature. SVN does, but we don't really have a common SVN. This is the canonical problem with binary formats -- more power in the binary-based tool (excel), but less collaboration ability. I suppose a sharepoint server would work...? But [I'm assuming] that would be a nightmare of licensing and access control setup. We could use a tex-based format (latex?) that allows merge capabilities, or use the wiki text format (but wikis don't handle simultaneous editing nicely -- someone inevitably "loses", rather than having the ability to merge their new text in). Splitting into mutliple files, each with a discrete author, might still be the best solution. [shrug] -- Jeff Squyres Cisco Systems _______________________________________________ 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.

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

Hi, The initial ABI proposal draft (see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/AbiWikiPage/MPI…) cites Bill Gropp's paper to introduce the MPI constant hierarchy basing on when the items are/should be defined according to the standard. We can use that hierarchy to split all ABI entities into groups. Here is the pertinent excerpt: - Compatible MPI data entities o Compile-time values § Used in declarations (MPI_MAX_ERROR_STRING, etc.) § Other (MPI_ANY_SOURCE, MPI_ERR_TRUNCATE, etc.) o Init-time constants (MPI_INT, etc.) o Opaque objects (MPI_Comm, MPI_Datatype, etc.) o Defined objects (MPI_Status) o Defined pointers (MPI_BOTTOM, MPI_STATUS_NULL, etc.) And while we're so focused on the mpi.h contents, I can't help reiterating that this is but a part of the ABI matter. The following is no less important for the whole thing to work: - Uniform approach to the macro implementation of certain functions (MPI_Wtime, MPI_Wtick, handle conversion calls, possibly others) - Similar calling convention o Argument order and size o Stack frame management policy o Return address storage and handling o Function call and return handling - Common linkage convention o Library file format o MPI library name o MPI library path resolution mechanism o System library dependency resolution Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Friday, April 25, 2008 6:01 PM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting I think that we need enough data to put the constants into classes of constants that are different from one implementation to the other (examples for a classes, are "handles", "datatype"). Once done, we'll be able to understand the differences in the different implementations (approach) and in the different platforms. This will enable us to come up with reasonable suggestion for the ABI constants. I think that putting the constants in different spreadsheet (split by os/cpu) is reasonable. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 7:04 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote: > The purpose of having as much input data as possible before deciding > whether and how to proceed is to not miss a potentially important data > point. > > In this vein, I'd love to see some MPICH1 and HP MPI data there. That, > with the data already in the spreadsheet, would most likely cover > 99% of > the currently targeted platforms (IA32/Intel64/Linux/Windows). I'm all for having enough data points. I was questioning how many we need -- it just looked like we we diverging into the "need dozens of datapoints" realm. If we're not, no problem. > A split into several files would make sense if we had dozens of > actively > contributing members. At the moment we are blessed with but a few. The wiki has no "lock" feature. SVN does, but we don't really have a common SVN. This is the canonical problem with binary formats -- more power in the binary-based tool (excel), but less collaboration ability. I suppose a sharepoint server would work...? But [I'm assuming] that would be a nightmare of licensing and access control setup. We could use a tex-based format (latex?) that allows merge capabilities, or use the wiki text format (but wikis don't handle simultaneous editing nicely -- someone inevitably "loses", rather than having the ability to merge their new text in). Splitting into mutliple files, each with a discrete author, might still be the best solution. [shrug] -- Jeff Squyres Cisco Systems _______________________________________________ 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.

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

I think that we need enough data to put the constants into classes of constants that are different from one implementation to the other (examples for a classes, are "handles", "datatype"). Once done, we'll be able to understand the differences in the different implementations (approach) and in the different platforms. This will enable us to come up with reasonable suggestion for the ABI constants. I think that putting the constants in different spreadsheet (split by os/cpu) is reasonable. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 7:04 AM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote: > The purpose of having as much input data as possible before deciding > whether and how to proceed is to not miss a potentially important data > point. > > In this vein, I'd love to see some MPICH1 and HP MPI data there. That, > with the data already in the spreadsheet, would most likely cover > 99% of > the currently targeted platforms (IA32/Intel64/Linux/Windows). I'm all for having enough data points. I was questioning how many we need -- it just looked like we we diverging into the "need dozens of datapoints" realm. If we're not, no problem. > A split into several files would make sense if we had dozens of > actively > contributing members. At the moment we are blessed with but a few. The wiki has no "lock" feature. SVN does, but we don't really have a common SVN. This is the canonical problem with binary formats -- more power in the binary-based tool (excel), but less collaboration ability. I suppose a sharepoint server would work...? But [I'm assuming] that would be a nightmare of licensing and access control setup. We could use a tex-based format (latex?) that allows merge capabilities, or use the wiki text format (but wikis don't handle simultaneous editing nicely -- someone inevitably "loses", rather than having the ability to merge their new text in). Splitting into mutliple files, each with a discrete author, might still be the best solution. [shrug] -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-abi mailing list mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

On Apr 25, 2008, at 8:32 AM, Supalov, Alexander wrote: > The purpose of having as much input data as possible before deciding > whether and how to proceed is to not miss a potentially important data > point. > > In this vein, I'd love to see some MPICH1 and HP MPI data there. That, > with the data already in the spreadsheet, would most likely cover > 99% of > the currently targeted platforms (IA32/Intel64/Linux/Windows). I'm all for having enough data points. I was questioning how many we need -- it just looked like we we diverging into the "need dozens of datapoints" realm. If we're not, no problem. > A split into several files would make sense if we had dozens of > actively > contributing members. At the moment we are blessed with but a few. The wiki has no "lock" feature. SVN does, but we don't really have a common SVN. This is the canonical problem with binary formats -- more power in the binary-based tool (excel), but less collaboration ability. I suppose a sharepoint server would work...? But [I'm assuming] that would be a nightmare of licensing and access control setup. We could use a tex-based format (latex?) that allows merge capabilities, or use the wiki text format (but wikis don't handle simultaneous editing nicely -- someone inevitably "loses", rather than having the ability to merge their new text in). Splitting into mutliple files, each with a discrete author, might still be the best solution. [shrug] -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

Well, if the goal is a common ABI then we have to expose the details in order to put together a proposal for the group. I don't see any other way to do it. As for the spreadsheet ... One way to do it would be to assign an "owner" for each of the columns on the spreadsheet. I will do the integration. Let's discuss at the WG session next week. I'd like to start getting into discussion of the ABI column. We should have enough data to get that rolling. Perhaps we will have something to propose at the next meeting (although this seems to pop up on everyones radar a week prior to the meeting - myself included). Jeff > On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: > >> I've reviewed the current spreadsheet. Note that according to our >> current observations, 64-bit Linux column covers Itanium Linux as >> well, >> as far as the contents of the MPICH2 mpi.h is concerned. I take this >> as >> an indication that we should not forget that ABI is more than mpi.h, >> and >> that we should be very specific in the platform description. >> >> Also, we might want to split Linux and Windows into different >> subsheets. >> Indeed, splitting into 32- and 64-bit might be helpful as well, as >> soon >> as the table becomes densely populated. I think this is something we >> should discuss when we see a joint ABI emerging. > > What is the goal for all of this analysis? I think we can already > tell that: > > - many MPI implementations have different fixed values for the same > MPI constants/etc. > - some MPI implementations have run-time determined values (e.g., > pointers) > - some MPI implementations change values/types based on the compiler > +platform that they are operating on > > Do we really need to make a comprehensive list of all MPI's on all > compiler+platforms to see these trends? Is there specific data that > would be gleaned from these vs. seeing a representative sample? > > (just trying to understand the purpose of the ever-expanding > spreadsheet) > >> I have a process question here: how do we prevent multiple updates >> running into each other, or overwriting each other accidentally? Is >> there a check-in/out feature in Wiki, or should we introduce a manual >> lock? Say, a file with a well known name to create before editing and >> delete afterwards? The name of the creator would show who's holding >> the >> lock. The modification date of the main file would show whether the >> copy >> you're working with is still actual. > > > How about creating separate spreadsheets, one for each MPI > implementation? This would allow for more-or-less independent updates. > > At some point in the future (when most changes have been complete), > they can be [re-]merged back into one spreadsheet. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-abi mailing list > mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi >

1 0

Re: [Mpi3-abi] For the April MPI Forum Meeting
by unknown＠example.com 25 Apr '08

25 Apr '08

Hi, The purpose of having as much input data as possible before deciding whether and how to proceed is to not miss a potentially important data point. In this vein, I'd love to see some MPICH1 and HP MPI data there. That, with the data already in the spreadsheet, would most likely cover 99% of the currently targeted platforms (IA32/Intel64/Linux/Windows). A split into several files would make sense if we had dozens of actively contributing members. At the moment we are blessed with but a few. Best regards. Alexander -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 25, 2008 12:41 PM To: MPI 3.0 ABI working group Subject: Re: [Mpi3-abi] For the April MPI Forum Meeting On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote: > I've reviewed the current spreadsheet. Note that according to our > current observations, 64-bit Linux column covers Itanium Linux as > well, > as far as the contents of the MPICH2 mpi.h is concerned. I take this > as > an indication that we should not forget that ABI is more than mpi.h, > and > that we should be very specific in the platform description. > > Also, we might want to split Linux and Windows into different > subsheets. > Indeed, splitting into 32- and 64-bit might be helpful as well, as > soon > as the table becomes densely populated. I think this is something we > should discuss when we see a joint ABI emerging. What is the goal for all of this analysis? I think we can already tell that: - many MPI implementations have different fixed values for the same MPI constants/etc. - some MPI implementations have run-time determined values (e.g., pointers) - some MPI implementations change values/types based on the compiler +platform that they are operating on Do we really need to make a comprehensive list of all MPI's on all compiler+platforms to see these trends? Is there specific data that would be gleaned from these vs. seeing a representative sample? (just trying to understand the purpose of the ever-expanding spreadsheet) > I have a process question here: how do we prevent multiple updates > running into each other, or overwriting each other accidentally? Is > there a check-in/out feature in Wiki, or should we introduce a manual > lock? Say, a file with a well known name to create before editing and > delete afterwards? The name of the creator would show who's holding > the > lock. The modification date of the main file would show whether the > copy > you're working with is still actual. How about creating separate spreadsheets, one for each MPI implementation? This would allow for more-or-less independent updates. At some point in the future (when most changes have been complete), they can be [re-]merged back into one spreadsheet. -- Jeff Squyres Cisco Systems _______________________________________________ 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.

1 0