- devel - mailman3.cels.anl.gov

Re: [mpich-devel] Future of MPE?
by Jeff Hammond 16 Oct '13

16 Oct '13

In what context is fast configure solving a real problem? Don Knuth would condemn such a thing IMO. Jeff ----- Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 16 October 2013 02:14, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > If you mean, I'll do configure/make/make install once and both mpich and mpe will be built, then probably not. This requires a lot of build system hacking for MPE's configure to test for MPI features before the MPI implementation is actually built. That's nasty; we already do that for the mpich test suite and it's a nightmare to maintain. We don't want to do that for yet another package. > > Would it make sense to have a "special" and fast configure step for > MPE when it is built as part of MPICH? > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169 -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Future of MPE?
by Lisandro Dalcin 16 Oct '13

16 Oct '13

On 16 October 2013 02:14, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > If you mean, I'll do configure/make/make install once and both mpich and mpe will be built, then probably not. This requires a lot of build system hacking for MPE's configure to test for MPI features before the MPI implementation is actually built. That's nasty; we already do that for the mpich test suite and it's a nightmare to maintain. We don't want to do that for yet another package. Would it make sense to have a "special" and fast configure step for MPE when it is built as part of MPICH? -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] Future of MPE?
by Pavan Balaji 15 Oct '13

15 Oct '13

With respect to the question on whether MPE will be distributed with mpich, the answer is it depends on what you mean by "distribute with mpich". If you mean, can you download one tarball and have code for both mpich and mpe, then sure, we can do that. If you mean, I'll do configure/make/make install once and both mpich and mpe will be built, then probably not. This requires a lot of build system hacking for MPE's configure to test for MPI features before the MPI implementation is actually built. That's nasty; we already do that for the mpich test suite and it's a nightmare to maintain. We don't want to do that for yet another package. Option 1 is not really more useful than downloading MPE from a separate URL and building it separately. That's the reason why we didn't do it. -- Pavan On Oct 15, 2013, at 5:29 PM, Jeff Hammond wrote: > Thanks for the info. If I get time to work on MPE, I'll see what I can do about the blocking issues noted below. > > Jeff > > ----- Original Message ----- >> From: "Pavan Balaji" <balaji(a)mcs.anl.gov> >> To: devel(a)mpich.org >> Sent: Tuesday, October 15, 2013 5:07:47 PM >> Subject: Re: [mpich-devel] Future of MPE? >> >> Jeff, >> >> There are a couple of things to be done in MPE: >> >> 1. The const bindings need to be added to bring it to MPI-3. Without >> this, it won't build. >> >> 2. The new MPI functions need to be added. This is a lower priority >> if people only need the MPI-2 functionality. >> >> 3. The tools that come with MPE (e.g., the coll checker) need to be >> updated for MPI-3. This is also a lower priority if people only >> need MPI-2. >> >> There is also some more cleanup that's needed (e.g., build system). >> >> Unfortunately, it's not on our priority list right now, given that >> there are many other MPI-3 features that need improvement. That's >> taking up all of our development bandwidth. But if someone is >> willing to work on it, we'll be happy to help out. >> >> -- Pavan >> >> On Oct 15, 2013, at 4:06 PM, Jeff Hammond wrote: >> >>> What is there to resurrect? Are you having trouble building MPE? >>> Why does it need to be distributed with MPICH to be viable? MPE >>> sits strictly on top of any MPI as far as I know. >>> >>> I have on my TODO list to migrate the existing HTML docs to >>> http://wiki.mpich.org/mpe/index.php/Main_Page but it's currently >>> in slot 17562 in the priority queue. >>> >>> Jeff >>> >>> ----- Original Message ----- >>>> From: "Lisandro Dalcin" <dalcinl(a)gmail.com> >>>> To: "mpich-devel" <devel(a)mpich.org> >>>> Sent: Tuesday, October 15, 2013 3:42:50 PM >>>> Subject: [mpich-devel] Future of MPE? >>>> >>>> Is there any plan to resurrect MPE and distribute it within >>>> mpich-3.x >>>> in the near future? >>>> >>>> -- >>>> Lisandro Dalcin >>>> --------------- >>>> CIMEC (UNL/CONICET) >>>> Predio CONICET-Santa Fe >>>> Colectora RN 168 Km 472, Paraje El Pozo >>>> 3000 Santa Fe, Argentina >>>> Tel: +54-342-4511594 (ext 1016) >>>> Tel/Fax: +54-342-4511169 >>>> >>> >>> -- >>> Jeff Hammond >>> Argonne Leadership Computing Facility >>> University of Chicago Computation Institute >>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>> http://www.linkedin.com/in/jeffhammond >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >>> ALCF docs: http://www.alcf.anl.gov/user-guides >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> >> > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > ALCF docs: http://www.alcf.anl.gov/user-guides > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] Future of MPE?
by Jeff Hammond 15 Oct '13

15 Oct '13

Thanks for the info. If I get time to work on MPE, I'll see what I can do about the blocking issues noted below. Jeff ----- Original Message ----- > From: "Pavan Balaji" <balaji(a)mcs.anl.gov> > To: devel(a)mpich.org > Sent: Tuesday, October 15, 2013 5:07:47 PM > Subject: Re: [mpich-devel] Future of MPE? > > Jeff, > > There are a couple of things to be done in MPE: > > 1. The const bindings need to be added to bring it to MPI-3. Without > this, it won't build. > > 2. The new MPI functions need to be added. This is a lower priority > if people only need the MPI-2 functionality. > > 3. The tools that come with MPE (e.g., the coll checker) need to be > updated for MPI-3. This is also a lower priority if people only > need MPI-2. > > There is also some more cleanup that's needed (e.g., build system). > > Unfortunately, it's not on our priority list right now, given that > there are many other MPI-3 features that need improvement. That's > taking up all of our development bandwidth. But if someone is > willing to work on it, we'll be happy to help out. > > -- Pavan > > On Oct 15, 2013, at 4:06 PM, Jeff Hammond wrote: > > > What is there to resurrect? Are you having trouble building MPE? > > Why does it need to be distributed with MPICH to be viable? MPE > > sits strictly on top of any MPI as far as I know. > > > > I have on my TODO list to migrate the existing HTML docs to > > http://wiki.mpich.org/mpe/index.php/Main_Page but it's currently > > in slot 17562 in the priority queue. > > > > Jeff > > > > ----- Original Message ----- > >> From: "Lisandro Dalcin" <dalcinl(a)gmail.com> > >> To: "mpich-devel" <devel(a)mpich.org> > >> Sent: Tuesday, October 15, 2013 3:42:50 PM > >> Subject: [mpich-devel] Future of MPE? > >> > >> Is there any plan to resurrect MPE and distribute it within > >> mpich-3.x > >> in the near future? > >> > >> -- > >> Lisandro Dalcin > >> --------------- > >> CIMEC (UNL/CONICET) > >> Predio CONICET-Santa Fe > >> Colectora RN 168 Km 472, Paraje El Pozo > >> 3000 Santa Fe, Argentina > >> Tel: +54-342-4511594 (ext 1016) > >> Tel/Fax: +54-342-4511169 > >> > > > > -- > > Jeff Hammond > > Argonne Leadership Computing Facility > > University of Chicago Computation Institute > > jhammond(a)alcf.anl.gov / (630) 252-5381 > > http://www.linkedin.com/in/jeffhammond > > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > ALCF docs: http://www.alcf.anl.gov/user-guides > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Future of MPE?
by Pavan Balaji 15 Oct '13

15 Oct '13

Jeff, There are a couple of things to be done in MPE: 1. The const bindings need to be added to bring it to MPI-3. Without this, it won't build. 2. The new MPI functions need to be added. This is a lower priority if people only need the MPI-2 functionality. 3. The tools that come with MPE (e.g., the coll checker) need to be updated for MPI-3. This is also a lower priority if people only need MPI-2. There is also some more cleanup that's needed (e.g., build system). Unfortunately, it's not on our priority list right now, given that there are many other MPI-3 features that need improvement. That's taking up all of our development bandwidth. But if someone is willing to work on it, we'll be happy to help out. -- Pavan On Oct 15, 2013, at 4:06 PM, Jeff Hammond wrote: > What is there to resurrect? Are you having trouble building MPE? Why does it need to be distributed with MPICH to be viable? MPE sits strictly on top of any MPI as far as I know. > > I have on my TODO list to migrate the existing HTML docs to http://wiki.mpich.org/mpe/index.php/Main_Page but it's currently in slot 17562 in the priority queue. > > Jeff > > ----- Original Message ----- >> From: "Lisandro Dalcin" <dalcinl(a)gmail.com> >> To: "mpich-devel" <devel(a)mpich.org> >> Sent: Tuesday, October 15, 2013 3:42:50 PM >> Subject: [mpich-devel] Future of MPE? >> >> Is there any plan to resurrect MPE and distribute it within mpich-3.x >> in the near future? >> >> -- >> Lisandro Dalcin >> --------------- >> CIMEC (UNL/CONICET) >> Predio CONICET-Santa Fe >> Colectora RN 168 Km 472, Paraje El Pozo >> 3000 Santa Fe, Argentina >> Tel: +54-342-4511594 (ext 1016) >> Tel/Fax: +54-342-4511169 >> > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > ALCF docs: http://www.alcf.anl.gov/user-guides -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] Error check in MPI_Type_get_[true_]extent_x()
by Rajeev Thakur 15 Oct '13

15 Oct '13

Thanks. I have added your note to the ticket. Rajeev On Oct 15, 2013, at 7:27 AM, Lisandro Dalcin wrote: > This is a followup on a previous thread in the old mpich-devel ML > (cannot find archives of the old list to link here) related to this > ticket http://trac.mpich.org/projects/mpich/ticket/1774 > > In my original report, I commented that the issue affected > MPI_Type_size_x() and MPI_Type_get_[true_]extent_x(). However, ticket > 1174 was filed only for handling MPI_Type_size_x(). > > By looking at the source code currently in master, it seems that > MPI_Type_get_[true_]extent_x() are coded to fail with uncommitted > user-defined datatypes. I think you are still missing the trivial > patch below: > > > diff --git a/src/mpi/datatype/type_get_extent_x.c > b/src/mpi/datatype/type_get_extent_x.c > index 94ba3a4..72f9db1 100644 > --- a/src/mpi/datatype/type_get_extent_x.c > +++ b/src/mpi/datatype/type_get_extent_x.c > @@ -99,7 +99,6 @@ int MPI_Type_get_extent_x(MPI_Datatype datatype, > MPI_Count *lb, MPI_Count *exten > MPID_Datatype *datatype_ptr = NULL; > MPID_Datatype_get_ptr(datatype, datatype_ptr); > MPID_Datatype_valid_ptr(datatype_ptr, mpi_errno); > - MPID_Datatype_committed_ptr(datatype_ptr, mpi_errno); > } > > /* TODO more checks may be appropriate (counts, in_place, > buffer aliasing, etc) */ > diff --git a/src/mpi/datatype/type_get_true_extent_x.c > b/src/mpi/datatype/type_get_true_extent_x.c > index c7b4f8f..4a6d9a9 100644 > --- a/src/mpi/datatype/type_get_true_extent_x.c > +++ b/src/mpi/datatype/type_get_true_extent_x.c > @@ -99,7 +99,6 @@ int MPI_Type_get_true_extent_x(MPI_Datatype > datatype, MPI_Count *true_lb, MPI_Co > MPID_Datatype *datatype_ptr = NULL; > MPID_Datatype_get_ptr(datatype, datatype_ptr); > MPID_Datatype_valid_ptr(datatype_ptr, mpi_errno); > - MPID_Datatype_committed_ptr(datatype_ptr, mpi_errno); > } > > /* TODO more checks may be appropriate (counts, in_place, > buffer aliasing, etc) */ > > > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] Future of MPE?
by Jeff Hammond 15 Oct '13

15 Oct '13

What is there to resurrect? Are you having trouble building MPE? Why does it need to be distributed with MPICH to be viable? MPE sits strictly on top of any MPI as far as I know. I have on my TODO list to migrate the existing HTML docs to http://wiki.mpich.org/mpe/index.php/Main_Page but it's currently in slot 17562 in the priority queue. Jeff ----- Original Message ----- > From: "Lisandro Dalcin" <dalcinl(a)gmail.com> > To: "mpich-devel" <devel(a)mpich.org> > Sent: Tuesday, October 15, 2013 3:42:50 PM > Subject: [mpich-devel] Future of MPE? > > Is there any plan to resurrect MPE and distribute it within mpich-3.x > in the near future? > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169 > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Future of MPE?
by Lisandro Dalcin 15 Oct '13

15 Oct '13

Is there any plan to resurrect MPE and distribute it within mpich-3.x in the near future? -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] when is MPICH going to be count-safe?
by Rob Latham 15 Oct '13

15 Oct '13

On Mon, Oct 14, 2013 at 09:54:56PM -0500, Rob Latham wrote: > good news is that I think everything "important" is happening > correctly. It's just that when the status object is updated it's > picking up an overflowed integer. status.count is MPI_Count big, so > that's not the source of the overflow. will look once more at my > mountain of clang -Wshorten-64-to-32 related warnings in the morning. Jeff found the casts to int and I've added his two patches to my branch in -review. Jeff and I now pass Jeff's testcase. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Error check in MPI_Type_get_[true_]extent_x()
by Lisandro Dalcin 15 Oct '13

15 Oct '13

This is a followup on a previous thread in the old mpich-devel ML (cannot find archives of the old list to link here) related to this ticket http://trac.mpich.org/projects/mpich/ticket/1774 In my original report, I commented that the issue affected MPI_Type_size_x() and MPI_Type_get_[true_]extent_x(). However, ticket 1174 was filed only for handling MPI_Type_size_x(). By looking at the source code currently in master, it seems that MPI_Type_get_[true_]extent_x() are coded to fail with uncommitted user-defined datatypes. I think you are still missing the trivial patch below: diff --git a/src/mpi/datatype/type_get_extent_x.c b/src/mpi/datatype/type_get_extent_x.c index 94ba3a4..72f9db1 100644 --- a/src/mpi/datatype/type_get_extent_x.c +++ b/src/mpi/datatype/type_get_extent_x.c @@ -99,7 +99,6 @@ int MPI_Type_get_extent_x(MPI_Datatype datatype, MPI_Count *lb, MPI_Count *exten MPID_Datatype *datatype_ptr = NULL; MPID_Datatype_get_ptr(datatype, datatype_ptr); MPID_Datatype_valid_ptr(datatype_ptr, mpi_errno); - MPID_Datatype_committed_ptr(datatype_ptr, mpi_errno); } /* TODO more checks may be appropriate (counts, in_place, buffer aliasing, etc) */ diff --git a/src/mpi/datatype/type_get_true_extent_x.c b/src/mpi/datatype/type_get_true_extent_x.c index c7b4f8f..4a6d9a9 100644 --- a/src/mpi/datatype/type_get_true_extent_x.c +++ b/src/mpi/datatype/type_get_true_extent_x.c @@ -99,7 +99,6 @@ int MPI_Type_get_true_extent_x(MPI_Datatype datatype, MPI_Count *true_lb, MPI_Co MPID_Datatype *datatype_ptr = NULL; MPID_Datatype_get_ptr(datatype, datatype_ptr); MPID_Datatype_valid_ptr(datatype_ptr, mpi_errno); - MPID_Datatype_committed_ptr(datatype_ptr, mpi_errno); } /* TODO more checks may be appropriate (counts, in_place, buffer aliasing, etc) */ -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0