July 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI_Send and recv
by Pavan Balaji 02 Jul '13

02 Jul '13

On 07/02/2013 05:18 PM, Sufeng Niu wrote: > Thanks a lot, that is most confusing part for me in MPI. I would like to > clear this type of problems. > > So the blocking begins to send message to itself, but there is no > receive posted. Thus, the MPI block it. Am I right here? Correct. > Thus, I need a nonblocking receive to wait the message here. Can I use > blocking receive? If you use blocking receive, you'll block in the receive; how will you reach the send? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] MPI_Send and recv
by Sufeng Niu 02 Jul '13

02 Jul '13

Hi, Pavan, Thanks a lot, that is most confusing part for me in MPI. I would like to clear this type of problems. So the blocking begins to send message to itself, but there is no receive posted. Thus, the MPI block it. Am I right here? Thus, I need a nonblocking receive to wait the message here. Can I use blocking receive? Hi Jeff, The weblink is https://computing.llnl.gov/tutorials/mpi/#Derived_Data_Types the code is second example. Thank you Thanks a lot! Sufeng On Tue, Jul 2, 2013 at 4:48 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > This is an incorrect program. You need to post an Irecv before sending to > yourself. > > -- Pavan > > > On 07/02/2013 04:39 PM, Sufeng Niu wrote: > >> Hi, >> >> I try to familiar with mpi self defined type api, and I directly run a >> very simple code from LLNL webpage: >> >> //----------------------------**------------------------------** >> ------------------------------**------- >> >> #include"mpi.h" >> #include <stdio.h> >> #define SIZE 4 >> >> int main(argc,argv) >> int argc; >> char *argv[]; { >> int numtasks, rank, source=0, dest, tag=1, i; >> float a[SIZE][SIZE] = >> {1.0, 2.0, 3.0, 4.0, >> 5.0, 6.0, 7.0, 8.0, >> 9.0, 10.0, 11.0, 12.0, >> 13.0, 14.0, 15.0, 16.0}; >> float b[SIZE]; >> >> MPI_Status stat; >> MPI_Datatype columntype; >> >> MPI_Init(&argc,&argv); >> MPI_Comm_rank(MPI_COMM_WORLD, &rank); >> MPI_Comm_size(MPI_COMM_WORLD, &numtasks); >> >> MPI_Type_vector(SIZE, 1, SIZE, MPI_FLOAT, &columntype); >> MPI_Type_commit(&columntype); >> >> if (numtasks == SIZE) { >> if (rank == 0) { >> for (i=0; i<numtasks; i++) >> MPI_Send(&a[0][i], 1, columntype, i, tag, MPI_COMM_WORLD); >> } >> >> MPI_Recv(b, SIZE, MPI_FLOAT, source, tag, MPI_COMM_WORLD, &stat); >> printf("rank= %d b= %3.1f %3.1f %3.1f %3.1f\n", >> rank,b[0],b[1],b[2],b[3]); >> } >> else >> printf("Must specify %d processors. Terminating.\n",SIZE); >> >> MPI_Type_free(&columntype); >> MPI_Finalize(); >> } >> >> //----------------------------**------------------------------** >> ------------------------------**------- >> >> However, it doesn't work. the program just suspend there. I figure out >> the problem is at line MPI_Send, and MPI_Recv. the MPI_Send just send it >> to itself. but I don't know why it doesn't work. Is it caused by dead >> lock? why? >> >> Thank you very much! >> >> -- >> Best Regards, >> Sufeng Niu >> ECASP lab, ECE department, Illinois Institute of Technology >> Tel: 312-731-7219 >> >> >> ______________________________**_________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/**mailman/listinfo/discuss<https://lists.mpich.org/mailman/listinfo/discuss> >> >> > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > -- Best Regards, Sufeng Niu ECASP lab, ECE department, Illinois Institute of Technology Tel: 312-731-7219

1 0

Re: [mpich-discuss] MPI_Send and recv
by Jeff Hammond 02 Jul '13

02 Jul '13

What's the web link for that program? I'll ask Blaise to fix it if it is incorrect (i.e. there was no error in transcription). jeff On Tue, Jul 2, 2013 at 4:48 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > This is an incorrect program. You need to post an Irecv before sending to > yourself. > > -- Pavan > > > On 07/02/2013 04:39 PM, Sufeng Niu wrote: >> >> Hi, >> >> I try to familiar with mpi self defined type api, and I directly run a >> very simple code from LLNL webpage: >> >> >> //----------------------------------------------------------------------------------------------- >> >> #include"mpi.h" >> #include <stdio.h> >> #define SIZE 4 >> >> int main(argc,argv) >> int argc; >> char *argv[]; { >> int numtasks, rank, source=0, dest, tag=1, i; >> float a[SIZE][SIZE] = >> {1.0, 2.0, 3.0, 4.0, >> 5.0, 6.0, 7.0, 8.0, >> 9.0, 10.0, 11.0, 12.0, >> 13.0, 14.0, 15.0, 16.0}; >> float b[SIZE]; >> >> MPI_Status stat; >> MPI_Datatype columntype; >> >> MPI_Init(&argc,&argv); >> MPI_Comm_rank(MPI_COMM_WORLD, &rank); >> MPI_Comm_size(MPI_COMM_WORLD, &numtasks); >> >> MPI_Type_vector(SIZE, 1, SIZE, MPI_FLOAT, &columntype); >> MPI_Type_commit(&columntype); >> >> if (numtasks == SIZE) { >> if (rank == 0) { >> for (i=0; i<numtasks; i++) >> MPI_Send(&a[0][i], 1, columntype, i, tag, MPI_COMM_WORLD); >> } >> >> MPI_Recv(b, SIZE, MPI_FLOAT, source, tag, MPI_COMM_WORLD, &stat); >> printf("rank= %d b= %3.1f %3.1f %3.1f %3.1f\n", >> rank,b[0],b[1],b[2],b[3]); >> } >> else >> printf("Must specify %d processors. Terminating.\n",SIZE); >> >> MPI_Type_free(&columntype); >> MPI_Finalize(); >> } >> >> >> //----------------------------------------------------------------------------------------------- >> >> However, it doesn't work. the program just suspend there. I figure out >> the problem is at line MPI_Send, and MPI_Recv. the MPI_Send just send it >> to itself. but I don't know why it doesn't work. Is it caused by dead >> lock? why? >> >> Thank you very much! >> >> -- >> Best Regards, >> Sufeng Niu >> ECASP lab, ECE department, Illinois Institute of Technology >> Tel: 312-731-7219 >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-discuss] MPI_Send and recv
by Pavan Balaji 02 Jul '13

02 Jul '13

This is an incorrect program. You need to post an Irecv before sending to yourself. -- Pavan On 07/02/2013 04:39 PM, Sufeng Niu wrote: > Hi, > > I try to familiar with mpi self defined type api, and I directly run a > very simple code from LLNL webpage: > > //----------------------------------------------------------------------------------------------- > > #include"mpi.h" > #include <stdio.h> > #define SIZE 4 > > int main(argc,argv) > int argc; > char *argv[]; { > int numtasks, rank, source=0, dest, tag=1, i; > float a[SIZE][SIZE] = > {1.0, 2.0, 3.0, 4.0, > 5.0, 6.0, 7.0, 8.0, > 9.0, 10.0, 11.0, 12.0, > 13.0, 14.0, 15.0, 16.0}; > float b[SIZE]; > > MPI_Status stat; > MPI_Datatype columntype; > > MPI_Init(&argc,&argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > MPI_Comm_size(MPI_COMM_WORLD, &numtasks); > > MPI_Type_vector(SIZE, 1, SIZE, MPI_FLOAT, &columntype); > MPI_Type_commit(&columntype); > > if (numtasks == SIZE) { > if (rank == 0) { > for (i=0; i<numtasks; i++) > MPI_Send(&a[0][i], 1, columntype, i, tag, MPI_COMM_WORLD); > } > > MPI_Recv(b, SIZE, MPI_FLOAT, source, tag, MPI_COMM_WORLD, &stat); > printf("rank= %d b= %3.1f %3.1f %3.1f %3.1f\n", > rank,b[0],b[1],b[2],b[3]); > } > else > printf("Must specify %d processors. Terminating.\n",SIZE); > > MPI_Type_free(&columntype); > MPI_Finalize(); > } > > //----------------------------------------------------------------------------------------------- > > However, it doesn't work. the program just suspend there. I figure out > the problem is at line MPI_Send, and MPI_Recv. the MPI_Send just send it > to itself. but I don't know why it doesn't work. Is it caused by dead > lock? why? > > Thank you very much! > > -- > Best Regards, > Sufeng Niu > ECASP lab, ECE department, Illinois Institute of Technology > Tel: 312-731-7219 > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

MPI_Send and recv
by Sufeng Niu 02 Jul '13

02 Jul '13

Hi, I try to familiar with mpi self defined type api, and I directly run a very simple code from LLNL webpage: //----------------------------------------------------------------------------------------------- #include "mpi.h" #include <stdio.h> #define SIZE 4 int main(argc,argv) int argc; char *argv[]; { int numtasks, rank, source=0, dest, tag=1, i; float a[SIZE][SIZE] = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0, 13.0, 14.0, 15.0, 16.0}; float b[SIZE]; MPI_Status stat;MPI_Datatype columntype; MPI_Init(&argc,&argv);MPI_Comm_rank(MPI_COMM_WORLD, &rank);MPI_Comm_size(MPI_COMM_WORLD, &numtasks); MPI_Type_vector(SIZE, 1, SIZE, MPI_FLOAT, &columntype);MPI_Type_commit(&columntype); if (numtasks == SIZE) { if (rank == 0) { for (i=0; i<numtasks; i++) MPI_Send(&a[0][i], 1, columntype, i, tag, MPI_COMM_WORLD); } MPI_Recv(b, SIZE, MPI_FLOAT, source, tag, MPI_COMM_WORLD, &stat); printf("rank= %d b= %3.1f %3.1f %3.1f %3.1f\n", rank,b[0],b[1],b[2],b[3]); } else printf("Must specify %d processors. Terminating.\n",SIZE); MPI_Type_free(&columntype);MPI_Finalize(); } //----------------------------------------------------------------------------------------------- However, it doesn't work. the program just suspend there. I figure out the problem is at line MPI_Send, and MPI_Recv. the MPI_Send just send it to itself. but I don't know why it doesn't work. Is it caused by dead lock? why? Thank you very much! -- Best Regards, Sufeng Niu ECASP lab, ECE department, Illinois Institute of Technology Tel: 312-731-7219

1 0

Re: [mpich-discuss] MPI_THREAD_MULTIPLE
by Bobby Philip 02 Jul '13

02 Jul '13

Jeff: I should have mentioned that the codes I am using for testing the performance are the latency tests that are at http://www.mcs.anl.gov/~thakur/thread-tests/ and not my AMR codes per se. Bobby On Tue, Jul 2, 2013 at 2:41 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I have done my own studies of this but only in detail on Blue Gene/Q, > which supports both fine-grain and fat locking to support > MPI_THREAD_MULTIPLE. > > I believe that CrayMPI takes a noticeable hit in MPI_THREAD_MULTIPLE > because their network hardware is very low latency and the software > overhead associated with locking (which is fat in their case AFAIK) is > noticeable by comparison. Is that the vendor in question? > > Do you have the option to aggregate communication and or otherwise use > MPI_THREAD_SERIALIZED instead? If not, then there really isn't an > alternative so comparative study will only make you a sad panda. > However, if you can use MPI_THREAD_SERIALIZED, perhaps with some > overhead, then you can compare the two implementations. > > It would be helpful if you could share code and system details. > > Best, > > Jeff > > On Mon, Jul 1, 2013 at 2:05 AM, Bobby Philip > <bphilip.kondekeril(a)gmail.com> wrote: > > Hi: > > > > Are there any studies that have been done on the effect of turning on > > MPI_THREAD_MULTIPLE with the latest versions of MPICH? I have an AMR > > application where halo or ghost updates require lots of small messages > to be > > sent/rec'd and I am currently seeing a performance hit with a vendor > > specific implementation based on MPICH2 and am trying to see whether > there > > are any implementations out there that might deliver better performance. > > > > Thanks, > > Bobby > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] MPI_THREAD_MULTIPLE
by Bobby Philip 02 Jul '13

02 Jul '13

Jeff: Thanks for your response. It is indeed a Cray system that I am working with. I'll try your suggestion of MPI_THREAD_SERIALIZED to see whether there is a difference and get back to you. I am already aggregating communication. Do you guys have any configure scripts tuned for Cray systems if I needed to install the latest mpich? Thanks! Bobby On Tue, Jul 2, 2013 at 2:41 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I have done my own studies of this but only in detail on Blue Gene/Q, > which supports both fine-grain and fat locking to support > MPI_THREAD_MULTIPLE. > > I believe that CrayMPI takes a noticeable hit in MPI_THREAD_MULTIPLE > because their network hardware is very low latency and the software > overhead associated with locking (which is fat in their case AFAIK) is > noticeable by comparison. Is that the vendor in question? > > Do you have the option to aggregate communication and or otherwise use > MPI_THREAD_SERIALIZED instead? If not, then there really isn't an > alternative so comparative study will only make you a sad panda. > However, if you can use MPI_THREAD_SERIALIZED, perhaps with some > overhead, then you can compare the two implementations. > > It would be helpful if you could share code and system details. > > Best, > > Jeff > > On Mon, Jul 1, 2013 at 2:05 AM, Bobby Philip > <bphilip.kondekeril(a)gmail.com> wrote: > > Hi: > > > > Are there any studies that have been done on the effect of turning on > > MPI_THREAD_MULTIPLE with the latest versions of MPICH? I have an AMR > > application where halo or ghost updates require lots of small messages > to be > > sent/rec'd and I am currently seeing a performance hit with a vendor > > specific implementation based on MPICH2 and am trying to see whether > there > > are any implementations out there that might deliver better performance. > > > > Thanks, > > Bobby > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] MPI_THREAD_MULTIPLE
by Jeff Hammond 01 Jul '13

01 Jul '13

I have done my own studies of this but only in detail on Blue Gene/Q, which supports both fine-grain and fat locking to support MPI_THREAD_MULTIPLE. I believe that CrayMPI takes a noticeable hit in MPI_THREAD_MULTIPLE because their network hardware is very low latency and the software overhead associated with locking (which is fat in their case AFAIK) is noticeable by comparison. Is that the vendor in question? Do you have the option to aggregate communication and or otherwise use MPI_THREAD_SERIALIZED instead? If not, then there really isn't an alternative so comparative study will only make you a sad panda. However, if you can use MPI_THREAD_SERIALIZED, perhaps with some overhead, then you can compare the two implementations. It would be helpful if you could share code and system details. Best, Jeff On Mon, Jul 1, 2013 at 2:05 AM, Bobby Philip <bphilip.kondekeril(a)gmail.com> wrote: > Hi: > > Are there any studies that have been done on the effect of turning on > MPI_THREAD_MULTIPLE with the latest versions of MPICH? I have an AMR > application where halo or ghost updates require lots of small messages to be > sent/rec'd and I am currently seeing a performance hit with a vendor > specific implementation based on MPICH2 and am trying to see whether there > are any implementations out there that might deliver better performance. > > Thanks, > Bobby > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-discuss] blcr problem
by Wesley Bland 01 Jul '13

01 Jul '13

There's been lots of turnover on the project recently so the previous experts for checkpoint/restart in MPICH are gone, but from what I can tell, it appears that it might currently be broken. This ticket (https://trac.mpich.org/projects/mpich/ticket/1144) is the only documentation about the subject that I can find, but I think the assumption is that everything has bit rotted and will need to be updated before it works again. Wesley On Jul 1, 2013, at 10:19 AM, basma a.azeem <basmaabdelazeem(a)hotmail.com> wrote: > i created a checkpoint file of the integer sort NPB after 60 sec of running the application , the checkpoint file size is 121.6 MB (121,633,453 bytes). > > i have Blcr for checkpoint/restart > when i try to restart from the checkpoint file i had , nothing happened , it just hangs > what i did wrong ? > this is the command i used. > > > basma@basma-Satellite-A500:~$ mpiexec -ckpointlib blcr \ > > -ckpoint-prefix /home/basma/ckpts/app.ckpoint \ > > -ckpoint-num 0 -n 4 > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] execvp error on file comm2_spawn_child
by Anne-Sophie Mouronval 01 Jul '13

01 Jul '13

Wesley, Thanks a lot for your help. I couldn't fix the bug using the key "wdir" of a MPI_INFO object, I had to use the key "path" to fix it. Now everything is OK. Regards, Anne-Sophie Le 7/1/13 4:23 PM, Wesley Bland a ï¿½crit : > The correct way of calling MPI_COMM_SPAWN is to create an MPI_INFO object with they key wdir set to the working directory you want to use for the spawned processes. The working directory for the parent process is not necessarily used for the spawned children. Alternatively, you can just use the full path and you don't need to worry about the working directory unless you have other parts of your application which use it (reading files, etc.). > > Wesley > > P.S. We no longer call the project MPICH2. It's just MPICH now as of version 3.x > > On Jul 1, 2013, at 8:19 AM, Anne-Sophie Mouronval <anne-sophie.mouronval(a)ecp.fr> wrote: > >> Hi, >> >> I've just installed Mpich2 (using 3.0.4 sources) on my computer and every thing works fine. >> >> Now, I have to work on MPI_Comm_spawn and I have some difficulties. >> >> I've found a nice example that is provided with Mpich2 sources in >> Mpich2/share/examples/logging >> This example is based on 2 files : comm2_spawn_parent.c and comm2_spawn_child.c. >> >> I've compiled these two files but I have an error when I try to run this test : >> >> $ mpiexec -np 2 ./comm2_spawn_parent >> [proxy:1:0@bambou] HYDU_create_process (./utils/launch/launch.c:75): execvp error on file comm2_spawn_child (No such file or directory) >> >> However, "comm2_spawn_child" is present in the current directory. >> >> Thus I've tried to use a "-path" option but it's not recognized : >> $mpiexec -path mypath -np 2 ./comm2_spawn_parent >> match_arg (./utils/args/args.c:160): unrecognized argument path >> >> I've looked for some documentation of this test but I haven't found anything. >> >> Regards, >> Anne-Sophie >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >

1 0