March 2010 - mpiwg-ft - mailman3.cels.anl.gov

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Richard Treumann 24 Mar '10

24 Mar '10

Sorry - I do not see how that solves the problem. Compiled application code allocates some number of bytes based on a structure declaration in C or a constant (MPI_STATUS_SIZE) in Fortran. Each byte in the structure is required because the MPI library has a use for it. There will not be spare bytes that can be used to cache the extra baggage. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: Greg Bronevetsky <bronevetsky1(a)llnl.gov> To: "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org>, "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org> Date: 03/24/2010 12:36 PM Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) Sent by: mpi3-ft-bounces(a)lists.mpi-forum.org >I agree with Dick. We're getting very strong ISV feedback that an >MPI-3 compatibility break will constitute a serious adoption barrier for them. The other option would be to have an extra function like MPI_Get_count that extracts internal information from MPI_Status objects. Can that be implemented without breaking compatibility? Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Supalov, Alexander 24 Mar '10

24 Mar '10

Let me think. How will this work if an old (MPI-2) based app is linked against a new (MPI-3) library? The app has already allocated the MPI_Status and that can't be changed without recompilation that is undesirable. It appears that in this scenario we'll have to have all "old" directly accessible data fields still inside the "new" MPI_Status, with the same sizes and offset/alignment, and then something else, not increasing the MPI_Status size, that can be used for the MPI_Get_count and additional MPI_Get_* functions. E.g., if the "old" internal "count" field (or whatever serves as such) could be "reused" to keep a pointer for all the MPI_Get_* functions - yes, this might work. Needs extra analysis at the implementation level, though. -----Original Message----- From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Greg Bronevetsky Sent: Wednesday, March 24, 2010 5:35 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group; MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) >I agree with Dick. We're getting very strong ISV feedback that an >MPI-3 compatibility break will constitute a serious adoption barrier for them. The other option would be to have an extra function like MPI_Get_count that extracts internal information from MPI_Status objects. Can that be implemented without breaking compatibility? Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft --------------------------------------------------------------------- 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-ft] FT Working Group Teleconf (today)
by Greg Bronevetsky 24 Mar '10

24 Mar '10

>I agree with Dick. We're getting very strong ISV feedback that an >MPI-3 compatibility break will constitute a serious adoption barrier for them. The other option would be to have an extra function like MPI_Get_count that extracts internal information from MPI_Status objects. Can that be implemented without breaking compatibility? Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Supalov, Alexander 24 Mar '10

24 Mar '10

I agree with Dick. We're getting very strong ISV feedback that an MPI-3 compatibility break will constitute a serious adoption barrier for them. From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Richard Treumann Sent: Wednesday, March 24, 2010 5:04 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) I know there have been suggestions that binary compatibility could be expendable. I am not aware of any decision that it is "not a goal" I remind you all that this survey did not use a good sampling technique. For example, I suspect most people who solve problems with a code that happens to be written in MPI want their code to just keep working and never saw the survey. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 [cid:[email protected]]Greg Bronevetsky ---03/24/2010 11:46:14 AM---At 07:13 AM 3/24/2010, Richard Treumann wrote: >I just took a look at the piggy back proposal. I do From: Greg Bronevetsky <bronevetsky1(a)llnl.gov> To: "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org>, "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org> Cc: Robert Blackmore/Poughkeepsie/IBM@IBMUS Date: 03/24/2010 11:46 AM Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) Sent by: mpi3-ft-bounces(a)lists.mpi-forum.org ________________________________ I don't believe that binary compatibility is a goal for MPI 3 and in the survey users rated it quite low on their priority list. Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft --------------------------------------------------------------------- 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-ft] FT Working Group Teleconf (today)
by Josh Hursey 24 Mar '10

24 Mar '10

I had to join late, but there was only one other person on the line. From the conversation on the list, it seems that most people are off focusing on other deadlines this week. So let's meet again in 2 weeks. I do not have any updates on the Async. process mgmt work at this time. Josh On Mar 24, 2010, at 9:27 AM, Josh Hursey wrote: > Reminder that we have a teleconf today, Wed 3/24/2010, at 12 noon EDT. > > Date: March 24, 2010 > Time: 12 noon EDT/New York > Dial-in information: > 877-801-8130 > Code: 1044056 > > Agenda: > - Piggybacking (Greg B., George B., Darius B) > - Async. process management (Josh H.) > - other items? > > Respond to the list if you have any additional topics that you wish > to cover. > > Rich will not be bale to attend today, so I am covering the call > setup. > > -- Josh > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Richard Treumann 24 Mar '10

24 Mar '10

I know there have been suggestions that binary compatibility could be expendable. I am not aware of any decision that it is "not a goal" I remind you all that this survey did not use a good sampling technique. For example, I suspect most people who solve problems with a code that happens to be written in MPI want their code to just keep working and never saw the survey. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: Greg Bronevetsky <bronevetsky1(a)llnl.gov> To: "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org>, "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org> Cc: Robert Blackmore/Poughkeepsie/IBM@IBMUS Date: 03/24/2010 11:46 AM Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) Sent by: mpi3-ft-bounces(a)lists.mpi-forum.org I don't believe that binary compatibility is a goal for MPI 3 and in the survey users rated it quite low on their priority list. Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Greg Bronevetsky 24 Mar '10

24 Mar '10

Same for me. A bunch of proposals are due this week and next. I'll be free for the next telecon. Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com At 06:34 AM 3/24/2010, George Bosilca wrote: >Josh, > >I will not be able to attend either, we have a hard deadline this afternoon. > >I did not have time to gather new results regarding the datatype >manipulations for piggybacking techniques, so my position didn't >change from the last Forum meeting. As a reminder, with few >optimizations in the MPI library the whole datatype cycle (creation, >commit and free) is under a micro-second (to be exact 0.86 on a 2Ghz >Intel machine). This has been done without any caching implemented >at the application level. > > Thanks, > george. > >On Mar 24, 2010, at 09:27 , Josh Hursey wrote: > > > Reminder that we have a teleconf today, Wed 3/24/2010, at 12 noon EDT. > > > > Date: March 24, 2010 > > Time: 12 noon EDT/New York > > Dial-in information: > > 877-801-8130 > > Code: 1044056 > > > > Agenda: > > - Piggybacking (Greg B., George B., Darius B) > > - Async. process management (Josh H.) > > - other items? > > > > Respond to the list if you have any additional topics that you > wish to cover. > > > > Rich will not be bale to attend today, so I am covering the call setup. > > > > -- Josh > > > > _______________________________________________ > > mpi3-ft mailing list > > mpi3-ft(a)lists.mpi-forum.org > > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > >_______________________________________________ >mpi3-ft mailing list >mpi3-ft(a)lists.mpi-forum.org >http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Greg Bronevetsky 24 Mar '10

24 Mar '10

At 07:13 AM 3/24/2010, Richard Treumann wrote: >I just took a look at the piggy back proposal. I do not see a >fundamental problem but there are a couple points worth a mention > >1) Mandating extra fields in a status object breaks binary >compatibility. An MPI library that assume it is filling in new form >status when the application was compiled with old form status will >trash some other part of memory. When a status was determined to be >a user allocated structure in MPI 1.0, the ability to change it was forfeited. I don't believe that binary compatibility is a goal for MPI 3 and in the survey users rated it quite low on their priority list. >2) Expecting libmpi to recognize that the piggyback sent was bigger >than the piggyback expected and truncate the piggyback while >delivering an intact user message is not going to be practical. The >MPI standard should treat this exactly the way it treats any >send/recv in which type signatures do not match. I.E. if total bytes >sent is <= total expected, the outcome is undefined and if total >bytes sent is > total expected it is an error and the resulting >buffer content is undefined. The standard only obliges libmpi to >refrain from trashing memory outside the footprint of the typemap. > >IBM uses an approach that distributes inbound packets (which may >arrive out of order) directly into the receive type map. If the >bytes coming in > expected we discard all packets and if <=, we put >the bytes wherever the recv side typemap says and have no way of >knowing the send type signature and recv type signature are >inconsistent. Adding metadata to validate send type signature >against recv type signature would be too expensive That's fair. We shouldn't make piggybacking semantics more stringent than regular application data semantics. Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 bronevetsky(a)llnl.gov http://greg.bronevetsky.com

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by Richard Treumann 24 Mar '10

24 Mar '10

I just took a look at the piggy back proposal. I do not see a fundamental problem but there are a couple points worth a mention 1) Mandating extra fields in a status object breaks binary compatibility. An MPI library that assume it is filling in new form status when the application was compiled with old form status will trash some other part of memory. When a status was determined to be a user allocated structure in MPI 1.0, the ability to change it was forfeited. 2) Expecting libmpi to recognize that the piggyback sent was bigger than the piggyback expected and truncate the piggyback while delivering an intact user message is not going to be practical. The MPI standard should treat this exactly the way it treats any send/recv in which type signatures do not match. I.E. if total bytes sent is <= total expected, the outcome is undefined and if total bytes sent is > total expected it is an error and the resulting buffer content is undefined. The standard only obliges libmpi to refrain from trashing memory outside the footprint of the typemap. IBM uses an approach that distributes inbound packets (which may arrive out of order) directly into the receive type map. If the bytes coming in > expected we discard all packets and if <=, we put the bytes wherever the recv side typemap says and have no way of knowing the send type signature and recv type signature are inconsistent. Adding metadata to validate send type signature against recv type signature would be too expensive . Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: George Bosilca <bosilca(a)eecs.utk.edu> To: "MPI 3.0 Fault Tolerance and Dynamic Process Control working Group" <mpi3-ft(a)lists.mpi-forum.org> Date: 03/24/2010 09:35 AM Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today) Sent by: mpi3-ft-bounces(a)lists.mpi-forum.org Josh, I will not be able to attend either, we have a hard deadline this afternoon. I did not have time to gather new results regarding the datatype manipulations for piggybacking techniques, so my position didn't change from the last Forum meeting. As a reminder, with few optimizations in the MPI library the whole datatype cycle (creation, commit and free) is under a micro-second (to be exact 0.86 on a 2Ghz Intel machine). This has been done without any caching implemented at the application level. Thanks, george. On Mar 24, 2010, at 09:27 , Josh Hursey wrote: > Reminder that we have a teleconf today, Wed 3/24/2010, at 12 noon EDT. > > Date: March 24, 2010 > Time: 12 noon EDT/New York > Dial-in information: > 877-801-8130 > Code: 1044056 > > Agenda: > - Piggybacking (Greg B., George B., Darius B) > - Async. process management (Josh H.) > - other items? > > Respond to the list if you have any additional topics that you wish to cover. > > Rich will not be bale to attend today, so I am covering the call setup. > > -- Josh > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft _______________________________________________ mpi3-ft mailing list mpi3-ft(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] FT Working Group Teleconf (today)
by George Bosilca 24 Mar '10

24 Mar '10

Josh, I will not be able to attend either, we have a hard deadline this afternoon. I did not have time to gather new results regarding the datatype manipulations for piggybacking techniques, so my position didn't change from the last Forum meeting. As a reminder, with few optimizations in the MPI library the whole datatype cycle (creation, commit and free) is under a micro-second (to be exact 0.86 on a 2Ghz Intel machine). This has been done without any caching implemented at the application level. Thanks, george. On Mar 24, 2010, at 09:27 , Josh Hursey wrote: > Reminder that we have a teleconf today, Wed 3/24/2010, at 12 noon EDT. > > Date: March 24, 2010 > Time: 12 noon EDT/New York > Dial-in information: > 877-801-8130 > Code: 1044056 > > Agenda: > - Piggybacking (Greg B., George B., Darius B) > - Async. process management (Josh H.) > - other items? > > Respond to the list if you have any additional topics that you wish to cover. > > Rich will not be bale to attend today, so I am covering the call setup. > > -- Josh > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0