- devel - mailman3.cels.anl.gov

Re: [mpich-devel] MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Junchao Zhang 24 May '14

24 May '14

Hi, Sam, Could you give me the exact number of MPI ranks for your results on Mira? I run hpgmg on Edison with export OMP_NUM_THREADS=1, aprun -n 64000 -ss -cc numa_node ./hpgmg-fv 6 1. The total time in MGBuild is about 0.005 seconds. I was wondering how many cores I need to apply to reproduce the problem. Thanks. --Junchao Zhang On Sat, May 17, 2014 at 9:06 AM, Sam Williams <swwilliams(a)lbl.gov> wrote: > I've been conducting scaling experiments on the Mira (Blue Gene/Q) and K > (Sparc) supercomputers. I've noticed that the time required for > MPI_Comm_split and MPI_Comm_dup can grow quickly with scale (~P^2). As > such, its performance eventually becomes a bottleneck. That is, although > the benefit of using a subcommunicator is huge (multigrid solves are > weak-scalable), the penalty of creating one (multigrid build time) is also > huge. > > For example, when scaling from 1 to 46K nodes (= cubes of integers) on > Mira, the time (in seconds) required to build a MG solver (including a > subcommunicator) scales as > 222335.output: Total time in MGBuild 0.056704 > 222336.output: Total time in MGBuild 0.060834 > 222348.output: Total time in MGBuild 0.064782 > 222349.output: Total time in MGBuild 0.090229 > 222350.output: Total time in MGBuild 0.075280 > 222351.output: Total time in MGBuild 0.091852 > 222352.output: Total time in MGBuild 0.137299 > 222411.output: Total time in MGBuild 0.301552 > 222413.output: Total time in MGBuild 0.606444 > 222415.output: Total time in MGBuild 0.745272 > 222417.output: Total time in MGBuild 0.779757 > 222418.output: Total time in MGBuild 4.671838 > 222419.output: Total time in MGBuild 15.123162 > 222420.output: Total time in MGBuild 33.875626 > 222421.output: Total time in MGBuild 49.494547 > 222422.output: Total time in MGBuild 151.329026 > > If I disable the call to MPI_Comm_Split, my time scales as > 224982.output: Total time in MGBuild 0.050143 > 224983.output: Total time in MGBuild 0.052607 > 224988.output: Total time in MGBuild 0.050697 > 224989.output: Total time in MGBuild 0.078343 > 224990.output: Total time in MGBuild 0.054634 > 224991.output: Total time in MGBuild 0.052158 > 224992.output: Total time in MGBuild 0.060286 > 225008.output: Total time in MGBuild 0.062925 > 225009.output: Total time in MGBuild 0.097357 > 225010.output: Total time in MGBuild 0.061807 > 225011.output: Total time in MGBuild 0.076617 > 225012.output: Total time in MGBuild 0.099683 > 225013.output: Total time in MGBuild 0.125580 > 225014.output: Total time in MGBuild 0.190711 > 225016.output: Total time in MGBuild 0.218329 > 225017.output: Total time in MGBuild 0.282081 > > Although I didn't directly measure it, this suggests the time for > MPI_Comm_Split is growing roughly quadratically with process concurrency. > > > > > I see the same effect on the K machine (8...64K nodes) where the code uses > comm_split/dup in conjunction: > run00008_7_1.sh.o2412931: Total time in MGBuild 0.026458 seconds > run00064_7_1.sh.o2415876: Total time in MGBuild 0.039121 seconds > run00512_7_1.sh.o2415877: Total time in MGBuild 0.086800 seconds > run01000_7_1.sh.o2414496: Total time in MGBuild 0.129764 seconds > run01728_7_1.sh.o2415878: Total time in MGBuild 0.224576 seconds > run04096_7_1.sh.o2415880: Total time in MGBuild 0.738979 seconds > run08000_7_1.sh.o2414504: Total time in MGBuild 2.123800 seconds > run13824_7_1.sh.o2415881: Total time in MGBuild 6.276573 seconds > run21952_7_1.sh.o2415882: Total time in MGBuild 13.634200 seconds > run32768_7_1.sh.o2415884: Total time in MGBuild 36.508670 seconds > run46656_7_1.sh.o2415874: Total time in MGBuild 58.668228 seconds > run64000_7_1.sh.o2415875: Total time in MGBuild 117.322217 seconds > > > A glance at the implementation on Mira (I don't know if the implementation > on K is stock) suggests it should be using qsort to sort based on keys. > Unfortunately, qsort is not performance robust like heap/merge sort. If > one were to be productive and call comm_split like... > MPI_Comm_split(...,mycolor,myrank,...) > then one runs the risk that the keys are presorted. This hits the worst > case computational complexity for qsort... O(P^2). Demanding programmers > avoid sending sorted keys seems unreasonable. > > > I should note, I see a similar lack of scaling with MPI_Comm_dup on the K > machine. Unfortunately, my BGQ data used an earlier version of the code > that did not use comm_dup. As such, I can’t definitively say that it is a > problem on that machine as well. > > Thus, I'm asking for scalable implementations of comm_split/dup using > merge/heap sort whose worst case complexity is still PlogP to be > prioritized in the next update. > > > thanks > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] (no subject)
by Lisandro Dalcin 21 May '14

21 May '14

On 21 May 2014 15:07, Chafik sanaa <san.chafik(a)gmail.com> wrote: > what do you mean by invalid rank ? this is my program : > Your code runs just fine using latest MPICH 3.1 in my Mac laptop when using 2 processes. My guess is that you executed your program with just one process instead of two. Please add a check to make sure your are using nprocs >= 2 (i.e, that the size of MPI_COMM_WORLD is at least two). PS: As Jeff said, this ML is not appropriate for general user questions. -- 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] (no subject)
by Jeff Hammond 21 May '14

21 May '14

This thread is not about MPICH development. Please post to the discuss list. And use an appropriate email subject in the future. It will endear you to the experts to use good email etiquette. Thanks, Jeff Sent from my iPhone > On May 21, 2014, at 6:07 AM, Chafik sanaa <san.chafik(a)gmail.com> wrote: > > what do you mean by invalid rank ? this is my program : > > #include "mpi.h" > #include <stdlib.h> > #include <stdio.h> > int main(int argc, char *argv[]) { > int rang,iter,iter2; > int nb_tests=9; > int nb_valeurs[9]; > int nb_valeurs_max=7000000; > int etiquette=99; > double *valeurs; > MPI_Status statut; > double temps_debut,temps_fin; > > MPI_Init( &argc, &argv); > > nb_valeurs[0]=0,nb_valeurs[1]=1,nb_valeurs[2]=10,nb_valeurs[3]=100; > nb_valeurs[4]=1000,nb_valeurs[5]=10000,nb_valeurs[6]=100000; > nb_valeurs[7]=1000000,nb_valeurs[8]=7000000; > > MPI_Comm_rank( MPI_COMM_WORLD, &rang); > > valeurs = (double *) malloc(nb_valeurs_max*sizeof(double)); > > for(iter=0; iter<nb_tests; iter++) { > if (rang == 0) { > for (iter2 = 0; iter2<nb_valeurs[iter]; iter2++) > valeurs[iter2] = rand() / (RAND_MAX + 1.); > temps_debut=MPI_Wtime(); > MPI_Send(valeurs,nb_valeurs[iter],MPI_DOUBLE,1,etiquette,MPI_COMM_WORLD); > MPI_Recv(valeurs,nb_valeurs[iter],MPI_DOUBLE,1,etiquette, > MPI_COMM_WORLD,&statut); > temps_fin=MPI_Wtime(); > if (nb_valeurs[iter] != 0) { > printf("Moi, processus 0, j'ai envoye et recu %8d valeurs" > "(derniere = %4.2f) du processus 1 en %8.6f secondes, soit " > "avec un debit de %7.2f Mo/s.\n", > nb_valeurs[iter], valeurs[nb_valeurs[iter]-1], > temps_fin-temps_debut, > 2.*nb_valeurs[iter]*8/1000000./(temps_fin-temps_debut)); > } else > printf("Moi, processus 0, j'ai envoye et recu %8d valeurs en %8.6f " > "secondes, soit avec un debit de %7.2f Mo/s.\n", > nb_valeurs[iter], temps_fin-temps_debut, > 2.*nb_valeurs[iter]*8/1000000./(temps_fin-temps_debut)); > } else if(rang == 1) { > MPI_Recv(valeurs,nb_valeurs[iter],MPI_DOUBLE,0,etiquette, > MPI_COMM_WORLD,&statut); > MPI_Send(valeurs,nb_valeurs[iter],MPI_DOUBLE,0,etiquette,MPI_COMM_WORLD); > } > } > > MPI_Finalize(); > return 0; > } > > > > 2014-05-21 15:03 GMT+02:00 Rob Latham <robl(a)mcs.anl.gov>: >> >> >>> On 05/21/2014 04:28 AM, Chafik sanaa wrote: >>> Hi, >>> I use the Microsoft HPC Pack 2008 R2 in the visual studio 2010 , when i >>> execute my program i have this error : >>> fatal error in pmpi_send invalid rank error stack PMPI_Send(150): >>> MPI_send(buf=... >>> What is the problem? >> >> uh, you passed an invalid rank to MPI_Send. >> >> ==rob >> >>> thank you >>> >>> >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] (no subject)
by Chafik sanaa 21 May '14

21 May '14

what do you mean by invalid rank ? this is my program : #include "mpi.h" #include <stdlib.h> #include <stdio.h> int main(int argc, char *argv[]) { int rang,iter,iter2; int nb_tests=9; int nb_valeurs[9]; int nb_valeurs_max=7000000; int etiquette=99; double *valeurs; MPI_Status statut; double temps_debut,temps_fin; MPI_Init( &argc, &argv); nb_valeurs[0]=0,nb_valeurs[1]=1,nb_valeurs[2]=10,nb_valeurs[3]=100; nb_valeurs[4]=1000,nb_valeurs[5]=10000,nb_valeurs[6]=100000; nb_valeurs[7]=1000000,nb_valeurs[8]=7000000; MPI_Comm_rank( MPI_COMM_WORLD, &rang); valeurs = (double *) malloc(nb_valeurs_max*sizeof(double)); for(iter=0; iter<nb_tests; iter++) { if (rang == 0) { for (iter2 = 0; iter2<nb_valeurs[iter]; iter2++) valeurs[iter2] = rand() / (RAND_MAX + 1.); temps_debut=MPI_Wtime(); MPI_Send(valeurs,nb_valeurs[iter],MPI_DOUBLE,1,etiquette,MPI_COMM_WORLD); MPI_Recv(valeurs,nb_valeurs[iter],MPI_DOUBLE,1,etiquette, MPI_COMM_WORLD,&statut); temps_fin=MPI_Wtime(); if (nb_valeurs[iter] != 0) { printf("Moi, processus 0, j'ai envoye et recu %8d valeurs" "(derniere = %4.2f) du processus 1 en %8.6f secondes, soit " "avec un debit de %7.2f Mo/s.\n", nb_valeurs[iter], valeurs[nb_valeurs[iter]-1], temps_fin-temps_debut, 2.*nb_valeurs[iter]*8/1000000./(temps_fin-temps_debut)); } else printf("Moi, processus 0, j'ai envoye et recu %8d valeurs en %8.6f " "secondes, soit avec un debit de %7.2f Mo/s.\n", nb_valeurs[iter], temps_fin-temps_debut, 2.*nb_valeurs[iter]*8/1000000./(temps_fin-temps_debut)); } else if(rang == 1) { MPI_Recv(valeurs,nb_valeurs[iter],MPI_DOUBLE,0,etiquette, MPI_COMM_WORLD,&statut); MPI_Send(valeurs,nb_valeurs[iter],MPI_DOUBLE,0,etiquette,MPI_COMM_WORLD); } } MPI_Finalize(); return 0; } 2014-05-21 15:03 GMT+02:00 Rob Latham <robl(a)mcs.anl.gov>: > > > On 05/21/2014 04:28 AM, Chafik sanaa wrote: > >> Hi, >> I use the Microsoft HPC Pack 2008 R2 in the visual studio 2010 , when i >> execute my program i have this error : >> fatal error in pmpi_send invalid rank error stack PMPI_Send(150): >> MPI_send(buf=... >> What is the problem? >> > > uh, you passed an invalid rank to MPI_Send. > > ==rob > > thank you >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] (no subject)
by Rob Latham 21 May '14

21 May '14

On 05/21/2014 04:28 AM, Chafik sanaa wrote: > Hi, > I use the Microsoft HPC Pack 2008 R2 in the visual studio 2010 , when i > execute my program i have this error : > fatal error in pmpi_send invalid rank error stack PMPI_Send(150): > MPI_send(buf=... > What is the problem? uh, you passed an invalid rank to MPI_Send. ==rob > thank you > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

(no subject)
by Chafik sanaa 21 May '14

21 May '14

Hi, I use the Microsoft HPC Pack 2008 R2 in the visual studio 2010 , when i execute my program i have this error : fatal error in pmpi_send invalid rank error stack PMPI_Send(150): MPI_send(buf=... What is the problem? thank you

1 0

Re: [mpich-devel] MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Rajeev Thakur 19 May '14

19 May '14

Sam, Thanks for the bug report. We will fix it. Rajeev On May 17, 2014, at 9:06 AM, Sam Williams <swwilliams(a)lbl.gov> wrote: > I've been conducting scaling experiments on the Mira (Blue Gene/Q) and K (Sparc) supercomputers. I've noticed that the time required for MPI_Comm_split and MPI_Comm_dup can grow quickly with scale (~P^2). As such, its performance eventually becomes a bottleneck. That is, although the benefit of using a subcommunicator is huge (multigrid solves are weak-scalable), the penalty of creating one (multigrid build time) is also huge. > > For example, when scaling from 1 to 46K nodes (= cubes of integers) on Mira, the time (in seconds) required to build a MG solver (including a subcommunicator) scales as > 222335.output: Total time in MGBuild 0.056704 > 222336.output: Total time in MGBuild 0.060834 > 222348.output: Total time in MGBuild 0.064782 > 222349.output: Total time in MGBuild 0.090229 > 222350.output: Total time in MGBuild 0.075280 > 222351.output: Total time in MGBuild 0.091852 > 222352.output: Total time in MGBuild 0.137299 > 222411.output: Total time in MGBuild 0.301552 > 222413.output: Total time in MGBuild 0.606444 > 222415.output: Total time in MGBuild 0.745272 > 222417.output: Total time in MGBuild 0.779757 > 222418.output: Total time in MGBuild 4.671838 > 222419.output: Total time in MGBuild 15.123162 > 222420.output: Total time in MGBuild 33.875626 > 222421.output: Total time in MGBuild 49.494547 > 222422.output: Total time in MGBuild 151.329026 > > If I disable the call to MPI_Comm_Split, my time scales as > 224982.output: Total time in MGBuild 0.050143 > 224983.output: Total time in MGBuild 0.052607 > 224988.output: Total time in MGBuild 0.050697 > 224989.output: Total time in MGBuild 0.078343 > 224990.output: Total time in MGBuild 0.054634 > 224991.output: Total time in MGBuild 0.052158 > 224992.output: Total time in MGBuild 0.060286 > 225008.output: Total time in MGBuild 0.062925 > 225009.output: Total time in MGBuild 0.097357 > 225010.output: Total time in MGBuild 0.061807 > 225011.output: Total time in MGBuild 0.076617 > 225012.output: Total time in MGBuild 0.099683 > 225013.output: Total time in MGBuild 0.125580 > 225014.output: Total time in MGBuild 0.190711 > 225016.output: Total time in MGBuild 0.218329 > 225017.output: Total time in MGBuild 0.282081 > > Although I didn't directly measure it, this suggests the time for MPI_Comm_Split is growing roughly quadratically with process concurrency. > > > > > I see the same effect on the K machine (8...64K nodes) where the code uses comm_split/dup in conjunction: > run00008_7_1.sh.o2412931: Total time in MGBuild 0.026458 seconds > run00064_7_1.sh.o2415876: Total time in MGBuild 0.039121 seconds > run00512_7_1.sh.o2415877: Total time in MGBuild 0.086800 seconds > run01000_7_1.sh.o2414496: Total time in MGBuild 0.129764 seconds > run01728_7_1.sh.o2415878: Total time in MGBuild 0.224576 seconds > run04096_7_1.sh.o2415880: Total time in MGBuild 0.738979 seconds > run08000_7_1.sh.o2414504: Total time in MGBuild 2.123800 seconds > run13824_7_1.sh.o2415881: Total time in MGBuild 6.276573 seconds > run21952_7_1.sh.o2415882: Total time in MGBuild 13.634200 seconds > run32768_7_1.sh.o2415884: Total time in MGBuild 36.508670 seconds > run46656_7_1.sh.o2415874: Total time in MGBuild 58.668228 seconds > run64000_7_1.sh.o2415875: Total time in MGBuild 117.322217 seconds > > > A glance at the implementation on Mira (I don't know if the implementation on K is stock) suggests it should be using qsort to sort based on keys. Unfortunately, qsort is not performance robust like heap/merge sort. If one were to be productive and call comm_split like... > MPI_Comm_split(...,mycolor,myrank,...) > then one runs the risk that the keys are presorted. This hits the worst case computational complexity for qsort... O(P^2). Demanding programmers avoid sending sorted keys seems unreasonable. > > > I should note, I see a similar lack of scaling with MPI_Comm_dup on the K machine. Unfortunately, my BGQ data used an earlier version of the code that did not use comm_dup. As such, I can’t definitively say that it is a problem on that machine as well. > > Thus, I'm asking for scalable implementations of comm_split/dup using merge/heap sort whose worst case complexity is still PlogP to be prioritized in the next update. > > > thanks > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] integration the MPICH2 into Visual studio 2010
by "Antonio J. Peña" 17 May '14

17 May '14

Hi Chafik, Sorry, due to their diversity and number, we cannot give support for the MPICH derivatives. Please contact directly MS support instead. Antonio On 05/17/2014 05:54 AM, Chafik sanaa wrote: > sorry , > I download the wrong picture, here's the good > > > 2014-05-17 11:39 GMT+01:00 Chafik sanaa <san.chafik(a)gmail.com > <mailto:[email protected]>>: > > Hi,thank you > I used the MS MPI, but when I execute my program it gives the > error at image (see attached piece). > I do not know this is because of what? > > > 2014-05-16 17:06 GMT+01:00 Lu, Huiwei <huiweilu(a)mcs.anl.gov > <mailto:[email protected]>>: > > Hi, Chafik, > > Unfortunately, due to lack of developer resources, MPICH is > not actively supported on the Windows platform. Please refer > to our FAQ for more information: > http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… > > We recommend you use Microsoft MPI, which can be found here: > http://msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx > <http://msdn.microsoft.com/en-us/library/bb524831%28v=vs.85%29.aspx> > > --- > Huiwei > > On May 15, 2014, at 5:39 PM, Chafik sanaa > <san.chafik(a)gmail.com <mailto:[email protected]>> wrote: > > > I want to know how integrate the MPICH2 into the Visual > Studion 2010, > > becaufe I always have this error > > error LNK2019: symbole externe non rï¿½solu _MPI_Finalize > > error LNK2019: symbole externe non rï¿½solu _MPI_Comm_rank > > error LNK2019: symbole externe non rï¿½solu _MPI_Comm_size > > error LNK2019: symbole externe non rï¿½solu _MPI_Init > > ... > > _______________________________________________ > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/devel > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > > > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- 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 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Sam Williams 17 May '14

17 May '14

I've been conducting scaling experiments on the Mira (Blue Gene/Q) and K (Sparc) supercomputers. I've noticed that the time required for MPI_Comm_split and MPI_Comm_dup can grow quickly with scale (~P^2). As such, its performance eventually becomes a bottleneck. That is, although the benefit of using a subcommunicator is huge (multigrid solves are weak-scalable), the penalty of creating one (multigrid build time) is also huge. For example, when scaling from 1 to 46K nodes (= cubes of integers) on Mira, the time (in seconds) required to build a MG solver (including a subcommunicator) scales as 222335.output: Total time in MGBuild 0.056704 222336.output: Total time in MGBuild 0.060834 222348.output: Total time in MGBuild 0.064782 222349.output: Total time in MGBuild 0.090229 222350.output: Total time in MGBuild 0.075280 222351.output: Total time in MGBuild 0.091852 222352.output: Total time in MGBuild 0.137299 222411.output: Total time in MGBuild 0.301552 222413.output: Total time in MGBuild 0.606444 222415.output: Total time in MGBuild 0.745272 222417.output: Total time in MGBuild 0.779757 222418.output: Total time in MGBuild 4.671838 222419.output: Total time in MGBuild 15.123162 222420.output: Total time in MGBuild 33.875626 222421.output: Total time in MGBuild 49.494547 222422.output: Total time in MGBuild 151.329026 If I disable the call to MPI_Comm_Split, my time scales as 224982.output: Total time in MGBuild 0.050143 224983.output: Total time in MGBuild 0.052607 224988.output: Total time in MGBuild 0.050697 224989.output: Total time in MGBuild 0.078343 224990.output: Total time in MGBuild 0.054634 224991.output: Total time in MGBuild 0.052158 224992.output: Total time in MGBuild 0.060286 225008.output: Total time in MGBuild 0.062925 225009.output: Total time in MGBuild 0.097357 225010.output: Total time in MGBuild 0.061807 225011.output: Total time in MGBuild 0.076617 225012.output: Total time in MGBuild 0.099683 225013.output: Total time in MGBuild 0.125580 225014.output: Total time in MGBuild 0.190711 225016.output: Total time in MGBuild 0.218329 225017.output: Total time in MGBuild 0.282081 Although I didn't directly measure it, this suggests the time for MPI_Comm_Split is growing roughly quadratically with process concurrency. I see the same effect on the K machine (8...64K nodes) where the code uses comm_split/dup in conjunction: run00008_7_1.sh.o2412931: Total time in MGBuild 0.026458 seconds run00064_7_1.sh.o2415876: Total time in MGBuild 0.039121 seconds run00512_7_1.sh.o2415877: Total time in MGBuild 0.086800 seconds run01000_7_1.sh.o2414496: Total time in MGBuild 0.129764 seconds run01728_7_1.sh.o2415878: Total time in MGBuild 0.224576 seconds run04096_7_1.sh.o2415880: Total time in MGBuild 0.738979 seconds run08000_7_1.sh.o2414504: Total time in MGBuild 2.123800 seconds run13824_7_1.sh.o2415881: Total time in MGBuild 6.276573 seconds run21952_7_1.sh.o2415882: Total time in MGBuild 13.634200 seconds run32768_7_1.sh.o2415884: Total time in MGBuild 36.508670 seconds run46656_7_1.sh.o2415874: Total time in MGBuild 58.668228 seconds run64000_7_1.sh.o2415875: Total time in MGBuild 117.322217 seconds A glance at the implementation on Mira (I don't know if the implementation on K is stock) suggests it should be using qsort to sort based on keys. Unfortunately, qsort is not performance robust like heap/merge sort. If one were to be productive and call comm_split like... MPI_Comm_split(...,mycolor,myrank,...) then one runs the risk that the keys are presorted. This hits the worst case computational complexity for qsort... O(P^2). Demanding programmers avoid sending sorted keys seems unreasonable. I should note, I see a similar lack of scaling with MPI_Comm_dup on the K machine. Unfortunately, my BGQ data used an earlier version of the code that did not use comm_dup. As such, I can’t definitively say that it is a problem on that machine as well. Thus, I'm asking for scalable implementations of comm_split/dup using merge/heap sort whose worst case complexity is still PlogP to be prioritized in the next update. thanks

1 0

Re: [mpich-devel] integration the MPICH2 into Visual studio 2010
by Chafik sanaa 17 May '14

17 May '14

sorry , I download the wrong picture, here's the good 2014-05-17 11:39 GMT+01:00 Chafik sanaa <san.chafik(a)gmail.com>: > Hi,thank you > I used the MS MPI, but when I execute my program it gives the error at > image (see attached piece). > I do not know this is because of what? > > > 2014-05-16 17:06 GMT+01:00 Lu, Huiwei <huiweilu(a)mcs.anl.gov>: > > Hi, Chafik, >> >> Unfortunately, due to lack of developer resources, MPICH is not actively >> supported on the Windows platform. Please refer to our FAQ for more >> information: >> >> http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… >> >> We recommend you use Microsoft MPI, which can be found here: >> http://msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx >> >> — >> Huiwei >> >> On May 15, 2014, at 5:39 PM, Chafik sanaa <san.chafik(a)gmail.com> wrote: >> >> > I want to know how integrate the MPICH2 into the Visual Studion 2010, >> > becaufe I always have this error >> > error LNK2019: symbole externe non résolu _MPI_Finalize >> > error LNK2019: symbole externe non résolu _MPI_Comm_rank >> > error LNK2019: symbole externe non résolu _MPI_Comm_size >> > error LNK2019: symbole externe non résolu _MPI_Init >> > ... >> > _______________________________________________ >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/devel >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> > >

1 0