- devel - mailman3.cels.anl.gov

Re: [mpich-devel] MPIR_ERRTEST_ARGNULL and count=0 (or type_size=0)
by Lisandro Dalcin 29 May '13

29 May '13

On 29 May 2013 22:49, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > It seems that I didn't understand MPI_BOTTOM completely, so the error > checks needed to be different than described below, but the high-level > issues are the same. > > Interested parties may consult > http://trac.mpich.org/projects/mpich/ticket/1863 for details and > further discussion. > Please take a look at the macro MPIR_ERRTEST_USERBUFFER . -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] MPIR_ERRTEST_ARGNULL and count=0 (or type_size=0)
by Jeff Hammond 29 May '13

29 May '13

It seems that I didn't understand MPI_BOTTOM completely, so the error checks needed to be different than described below, but the high-level issues are the same. Interested parties may consult http://trac.mpich.org/projects/mpich/ticket/1863 for details and further discussion. Jeff On Wed, May 29, 2013 at 7:41 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > I see Jim used MPIR_ERRTEST_ARGNULL in (r)get_accumulate, which makes > sense (I am working on verifying that they should be in the others as > well). However, these calls are not guarded by "if (count)", which > means that one presumably (I have not written a test for it but it > seems obvious) cannot use addr=NULL with count=0. It seems to me that > 0-byte transfers are find with NULL buffers (this was recently > verified for MPI_Ssend because it's a common way to implement p2p > synchronization). > > It seems prudent to change something like this: > > MPIR_ERRTEST_COUNT(origin_count, mpi_errno); > MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", > mpi_errno); > MPIR_ERRTEST_ARGNULL(origin_addr, "origin_addr", mpi_errno); > > To this: > > MPIR_ERRTEST_COUNT(origin_count, mpi_errno); > MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", > mpi_errno); > if (origin_count) MPIR_ERRTEST_ARGNULL(origin_addr, > "origin_addr", mpi_errno); > > Then I got to thinking, what if someone - almost certainly not > intentionally but because of a general implementation - uses > MPI_Type_vector to create a zero-length vector type. I don't see why > one can't do a count>0 transfer with with a NULL buffer if the > datatype is empty. > > I wrote the following test of a 0-length vector and see that it works > just fine with bcast. > > #include <stdio.h> > #include <stdlib.h> > > #include <mpi.h> > > int main(int argc, char ** argv) { > int rank, nproc; > MPI_Datatype emptyvec; > MPI_Aint lb, ext; > > MPI_Init(&argc, &argv); > > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > MPI_Comm_size(MPI_COMM_WORLD, &nproc); > > if (rank == 0) printf("Starting MPI datatype test with %d > processes\n", nproc); > > MPI_Type_vector(0,0,0,MPI_DOUBLE,&emptyvec); > MPI_Type_commit(&emptyvec); > MPI_Type_get_extent(emptyvec, &lb, &ext); > MPI_Type_size(emptyvec, &size); > if (rank == 0) printf("lb = %zu ext = %zu size = %d \n", lb, ext, size); > > MPI_Bcast(NULL, 0, emptyvec, 0, MPI_COMM_WORLD); > MPI_Bcast(NULL, 1, emptyvec, 0, MPI_COMM_WORLD); > > MPI_Type_free(&emptyvec); > > if (rank == 0) printf("Test complete: PASS.\n"); > > MPI_Finalize(); > > return 0; > } > > This suggests that it should be valid to use addr=NULL and count>0 as > long as the extent of the type is 0, hence the aforementioned code > should really be: > > int origin_datatype_size; > ... > MPIR_ERRTEST_COUNT(origin_count, mpi_errno); > MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", > mpi_errno); > MPID_Datatype_get_size_macro(origin_datatype, origin_datatype_size); > if (origin_count && origin_datatype_size) > MPIR_ERRTEST_ARGNULL(origin_addr, "origin_addr", mpi_errno); > > Do people agree with this reasoning? > > Thanks, > > Jeff > > -- > 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 -- 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

"create new ticket" text
by Michael Blocksome 29 May '13

29 May '13

FYI, the text on the trac page ... https://trac.mpich.org/projects/mpich/newticket ... talks about "MPICH2" and "mpich-discuss(a)mcs.anl.org". I think these terms have migrated away by now. Michael Blocksome Blue Gene Messaging blocksom(a)us.ibm.com

1 0

MPIR_ERRTEST_ARGNULL and count=0 (or type_size=0)
by Jeff Hammond 29 May '13

29 May '13

I see Jim used MPIR_ERRTEST_ARGNULL in (r)get_accumulate, which makes sense (I am working on verifying that they should be in the others as well). However, these calls are not guarded by "if (count)", which means that one presumably (I have not written a test for it but it seems obvious) cannot use addr=NULL with count=0. It seems to me that 0-byte transfers are find with NULL buffers (this was recently verified for MPI_Ssend because it's a common way to implement p2p synchronization). It seems prudent to change something like this: MPIR_ERRTEST_COUNT(origin_count, mpi_errno); MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", mpi_errno); MPIR_ERRTEST_ARGNULL(origin_addr, "origin_addr", mpi_errno); To this: MPIR_ERRTEST_COUNT(origin_count, mpi_errno); MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", mpi_errno); if (origin_count) MPIR_ERRTEST_ARGNULL(origin_addr, "origin_addr", mpi_errno); Then I got to thinking, what if someone - almost certainly not intentionally but because of a general implementation - uses MPI_Type_vector to create a zero-length vector type. I don't see why one can't do a count>0 transfer with with a NULL buffer if the datatype is empty. I wrote the following test of a 0-length vector and see that it works just fine with bcast. #include <stdio.h> #include <stdlib.h> #include <mpi.h> int main(int argc, char ** argv) { int rank, nproc; MPI_Datatype emptyvec; MPI_Aint lb, ext; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &nproc); if (rank == 0) printf("Starting MPI datatype test with %d processes\n", nproc); MPI_Type_vector(0,0,0,MPI_DOUBLE,&emptyvec); MPI_Type_commit(&emptyvec); MPI_Type_get_extent(emptyvec, &lb, &ext); MPI_Type_size(emptyvec, &size); if (rank == 0) printf("lb = %zu ext = %zu size = %d \n", lb, ext, size); MPI_Bcast(NULL, 0, emptyvec, 0, MPI_COMM_WORLD); MPI_Bcast(NULL, 1, emptyvec, 0, MPI_COMM_WORLD); MPI_Type_free(&emptyvec); if (rank == 0) printf("Test complete: PASS.\n"); MPI_Finalize(); return 0; } This suggests that it should be valid to use addr=NULL and count>0 as long as the extent of the type is 0, hence the aforementioned code should really be: int origin_datatype_size; ... MPIR_ERRTEST_COUNT(origin_count, mpi_errno); MPIR_ERRTEST_DATATYPE(origin_datatype, "origin_datatype", mpi_errno); MPID_Datatype_get_size_macro(origin_datatype, origin_datatype_size); if (origin_count && origin_datatype_size) MPIR_ERRTEST_ARGNULL(origin_addr, "origin_addr", mpi_errno); Do people agree with this reasoning? Thanks, Jeff -- 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] s/bcopy/memmove/
by Pavan Balaji 18 May '13

18 May '13

Jeff, Can you send the full changeset as a single git-formatted patch? -- Pavan On 05/18/2013 09:15 PM US Central Time, Jeff Hammond wrote: > (background: i previously replaced all instances of bzero with memset > but only ibm@mpich was copied) > > there was only one instance of bopy that wasn't macro-ed to memmove > already so i fixed it. patch attached. > > jeff > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

s/bcopy/memmove/
by Jeff Hammond 18 May '13

18 May '13

(background: i previously replaced all instances of bzero with memset but only ibm@mpich was copied) there was only one instance of bopy that wasn't macro-ed to memmove already so i fixed it. patch attached. jeff -- 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] mpich.org is down?
by Jeff Hammond 09 May '13

09 May '13

Just thank the good lord that we're using Git now and you aren't completely foobarred by the lack of Argonne internets. Jeff On Thu, May 9, 2013 at 2:05 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > mpich.org is still unreachable though. Should be fixed soon. > > On May 9, 2013, at 2:04 PM, Antonio J. Peña wrote: > >> >> Dear Michael, >> >> We experienced a network issue at institutional level. It seems to be solved right now. >> >> Antonio >> >> >> On Thursday, May 09, 2013 11:03:30 AM Michael Blocksome wrote: >> I can't access the git repositories or the trac database on mpich.org. Any ideas? >> >> Michael Blocksome >> Blue Gene Messaging >> blocksom(a)us.ibm.com >> >> >> >> -- >> Antonio J. Peña >> Postdoctoral Appointee >> Mathematics and Computer Science Division >> Argonne National Laboratory >> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >> Argonne, IL 60439-4847 >> (+1) 630-252-7928 >> apenya(a)mcs.anl.gov >> > -- 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] mpich.org is down?
by Rajeev Thakur 09 May '13

09 May '13

mpich.org is still unreachable though. Should be fixed soon. On May 9, 2013, at 2:04 PM, Antonio J. Peña wrote: > > Dear Michael, > > We experienced a network issue at institutional level. It seems to be solved right now. > > Antonio > > > On Thursday, May 09, 2013 11:03:30 AM Michael Blocksome wrote: > I can't access the git repositories or the trac database on mpich.org. Any ideas? > > Michael Blocksome > Blue Gene Messaging > blocksom(a)us.ibm.com > > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847 > (+1) 630-252-7928 > apenya(a)mcs.anl.gov >

1 0

Re: [mpich-devel] mpich.org is down?
by Antonio J. Peña 09 May '13

09 May '13

Dear Michael, We experienced a network issue at institutional level. It seems to be solved right now. Antonio On Thursday, May 09, 2013 11:03:30 AM Michael Blocksome wrote: I can't access the git repositories or the trac database on mpich.org. Any ideas? Michael Blocksome Blue Gene Messaging blocksom(a)us.ibm.com -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 (+1) 630-252-7928 apenya(a)mcs.anl.gov

1 0

mpich.org is down?
by Michael Blocksome 09 May '13

09 May '13

I can't access the git repositories or the trac database on mpich.org. Any ideas? Michael Blocksome Blue Gene Messaging blocksom(a)us.ibm.com

1 0