May 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] process failing...
by "Antonio J. Peña" 23 May '14

23 May '14

Hi Ron, It looks like at least one of your processes is receiving too many unexpected messages, leading to get out of memory. Unexpected messages are those not matching a posted receive on the receiver side. You may check with the application developers to make them review the algorithm or look for any possible bug. Antonio On 05/22/2014 08:51 PM, Ron Palmer wrote: > All, > I have been trying to run an inversion process (magsen3d) that > calculates a large matrix, perhaps in the order of 5-10GB. It takes > about 3 days on my cluster however, it fails towards the end, when it > is trying to bring in the bits and pieces calculated from the three > computers that shares the load (3 rack computers, each 2 CPUs). I > have attached a screenshot of the output at failure, including the > command that starts the process. All output after "0 5 10 ... 95 100" > are error messages of some sort or other. > > This problem may be with the actual application (magsen3d) or hardware > on these computers and not with MPICH2, I have no idea but I will ask > the programmers as well (and they may also be on this list). I have > cut back on number of nodes (threads/cores) I used as there were > previously errors in /var/log about out of memory. However, this time > there are no messages in any of those logs on any of these three > computers. > > If any of you could help me assess whether this is a problem with > MPICH2 or something else, then that would be a huge help to me. I am > running Centos on two of the computers including turner, and RH on the > third. Let me know if there are any additional info you may need. > > Thanks, > Ron > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- 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

Re: [mpich-discuss] Error: "MPIR_Get_contextid_sparse_group(1193): Too many communicators (0/2048)"
by Ted Sariyski 23 May '14

23 May '14

I need a little bit more help. My question relates to the structure of the array (referred below as A), for which a window object will be created. Let say that particles are of type particle_t: type particle_t integer :: host, id,... real,pointer :: data(:)=>null() end type particle_t I built two corresponding mpi types, one with data allocated, /mpi_particles_t/, and /mpi_particles_null_t/, when p%data=>null(). What I want to do is the following: 1. All processes allocates an array of type particles_t for *all* particles, but data is allocated only if a particle is assigned to the domain: /allocate(A(tot_num_particles)) do n=1,tot_num_particles if ( particle(n)%host == myid) allocate(particle(n)%data(data_size)) enddo/ 2. All processes create their mpi data type mpi_A_t: /do n=1//,//tot_num_particles// //if ( particle(n)%host == myid) then // // blockcounts(n) = 1 ; oldtypes(n) = mpi_particles_t// // else // // blockcounts(n) = 1 ; oldtypes(n) = mpi_particles_null_t// / / endif/ / call MPI_GET_ADDRESS(A(n), offsets(n), ierr)// // enddo/ /call mpi_type_create_struct(//tot_num_particles//,blockcounts,offsets,oldtypes,mpi_A_myid_t,ierr)// // call mpi_type_commit(mpi_A_myid_t,ierr) /I gave a try but it fails. Before I proceed I want to make sure that there is nothing fundamentally wrong with this approach. Besides, even if it is correct, I am not sure that this is the 'best' solution. I will highly appreciate your comments. Thanks in advance, --Ted / /// On 05/22/2014 03:31 PM, Ted Sariyski wrote: > I see. Thanks a lot. > --Ted > > > On 05/22/2014 03:15 PM, Rajeev Thakur wrote: >>> What do you mean with: "Why canï¿½t all processes open one large >>> window?" I guess I miss something. >> If each process has an array of objects that belong to it (called >> array A say) , then with a single call to MPI_Win_create you can >> create a window object that has everyone's A arrays in it. >> >> Rajeev >> >> >> >> On May 22, 2014, at 9:46 AM, Ted Sariyski <tsariysk(a)craft-tech.com> >> wrote: >> >>> It is about MPI_win. Here is the problem as it relates to MPI (it is >>> a Boltzmann type equation). >>> >>> There are N particles interacting with each other. Interaction is >>> directional, so that a particle interacts only with those particles, >>> which are within a narrow cone. The first step is to segregate the >>> initial set of N particles into subsets of particles (I called it >>> 'objects'), which interact with each other. Here is what I do: >>> ï¿½ Assign each object to a process. >>> ï¿½ The process which owns a object: >>> ï¿½ Makes a guess for the maximum number of particles expected >>> in this object. >>> ï¿½ Allocates memory for it. >>> ï¿½ Opens a shared window. >>> ï¿½ All processes >>> ï¿½ Each particle identify which object it belongs to, and >>> PUTs its data there. >>> ï¿½ After assembly is done, objects are passed to a solver. >>> ï¿½ Repeat >>> What do you mean with: "Why canï¿½t all processes open one large >>> window?" I guess I miss something. >>> Thanks, >>> --Ted >>> >>> >>> On 05/21/2014 11:03 PM, Balaji, Pavan wrote: >>>> On May 21, 2014, at 6:02 PM, Ted Sariyski <tsariysk(a)craft-tech.com> >>>> wrote: >>>> >>>>> Memory limitations. With one large window all processes have to >>>>> allocate memory for the objects they own as well as for objects >>>>> assigned to other process. >>>>> >>>> Are we talking about the same thing here? Iï¿½m referring to an >>>> MPI_Win. What objects do processes need to keep track of? >>>> >>>> ï¿½ Pavan >>>> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss(a)mpich.org >>>> >>>> To manage subscription options or unsubscribe: >>>> >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > >

1 0

process failing...
by Ron Palmer 22 May '14

22 May '14

All, I have been trying to run an inversion process (magsen3d) that calculates a large matrix, perhaps in the order of 5-10GB. It takes about 3 days on my cluster however, it fails towards the end, when it is trying to bring in the bits and pieces calculated from the three computers that shares the load (3 rack computers, each 2 CPUs). I have attached a screenshot of the output at failure, including the command that starts the process. All output after "0 5 10 ... 95 100" are error messages of some sort or other. This problem may be with the actual application (magsen3d) or hardware on these computers and not with MPICH2, I have no idea but I will ask the programmers as well (and they may also be on this list). I have cut back on number of nodes (threads/cores) I used as there were previously errors in /var/log about out of memory. However, this time there are no messages in any of those logs on any of these three computers. If any of you could help me assess whether this is a problem with MPICH2 or something else, then that would be a huge help to me. I am running Centos on two of the computers including turner, and RH on the third. Let me know if there are any additional info you may need. Thanks, Ron

1 0

Does MPICH support launching processes on Intel-MIC from host?
by Yida Wang 22 May '14

22 May '14

Hi Guys, Can MPICH be configured to support launching processes on Intel-MIC from the host? I know that there's a way to compile MPICH to be running on Intel-MIC only, but how about running heterogeneously on both host and Intel-MIC together? My compiled version returned "hydra_pmi_proxy: cannot execute binary file" and got stuck when I tried to launch processes on Intel-MIC. Thanks, YW

1 0

Re: [mpich-discuss] Error: "MPIR_Get_contextid_sparse_group(1193): Too many communicators (0/2048)"
by Ted Sariyski 22 May '14

22 May '14

I see. Thanks a lot. --Ted On 05/22/2014 03:15 PM, Rajeev Thakur wrote: >> What do you mean with: "Why canï¿½t all processes open one large window?" I guess I miss something. > If each process has an array of objects that belong to it (called array A say) , then with a single call to MPI_Win_create you can create a window object that has everyone's A arrays in it. > > Rajeev > > > > On May 22, 2014, at 9:46 AM, Ted Sariyski <tsariysk(a)craft-tech.com> wrote: > >> It is about MPI_win. Here is the problem as it relates to MPI (it is a Boltzmann type equation). >> >> There are N particles interacting with each other. Interaction is directional, so that a particle interacts only with those particles, which are within a narrow cone. The first step is to segregate the initial set of N particles into subsets of particles (I called it 'objects'), which interact with each other. Here is what I do: >> ï¿½ Assign each object to a process. >> ï¿½ The process which owns a object: >> ï¿½ Makes a guess for the maximum number of particles expected in this object. >> ï¿½ Allocates memory for it. >> ï¿½ Opens a shared window. >> ï¿½ All processes >> ï¿½ Each particle identify which object it belongs to, and PUTs its data there. >> ï¿½ After assembly is done, objects are passed to a solver. >> ï¿½ Repeat >> What do you mean with: "Why canï¿½t all processes open one large window?" I guess I miss something. >> Thanks, >> --Ted >> >> >> On 05/21/2014 11:03 PM, Balaji, Pavan wrote: >>> On May 21, 2014, at 6:02 PM, Ted Sariyski <tsariysk(a)craft-tech.com> >>> wrote: >>> >>>> Memory limitations. With one large window all processes have to allocate memory for the objects they own as well as for objects assigned to other process. >>>> >>> Are we talking about the same thing here? Iï¿½m referring to an MPI_Win. What objects do processes need to keep track of? >>> >>> ï¿½ Pavan >>> >>> _______________________________________________ >>> discuss mailing list >>> discuss(a)mpich.org >>> >>> To manage subscription options or unsubscribe: >>> >>> https://lists.mpich.org/mailman/listinfo/discuss >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ > 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] Error: "MPIR_Get_contextid_sparse_group(1193): Too many communicators (0/2048)"
by Rajeev Thakur 22 May '14

22 May '14

> What do you mean with: "Why can’t all processes open one large window?" I guess I miss something. If each process has an array of objects that belong to it (called array A say) , then with a single call to MPI_Win_create you can create a window object that has everyone's A arrays in it. Rajeev On May 22, 2014, at 9:46 AM, Ted Sariyski <tsariysk(a)craft-tech.com> wrote: > It is about MPI_win. Here is the problem as it relates to MPI (it is a Boltzmann type equation). > > There are N particles interacting with each other. Interaction is directional, so that a particle interacts only with those particles, which are within a narrow cone. The first step is to segregate the initial set of N particles into subsets of particles (I called it 'objects'), which interact with each other. Here is what I do: > • Assign each object to a process. > • The process which owns a object: > • Makes a guess for the maximum number of particles expected in this object. > • Allocates memory for it. > • Opens a shared window. > • All processes > • Each particle identify which object it belongs to, and PUTs its data there. > • After assembly is done, objects are passed to a solver. > • Repeat > What do you mean with: "Why can’t all processes open one large window?" I guess I miss something. > Thanks, > --Ted > > > On 05/21/2014 11:03 PM, Balaji, Pavan wrote: >> On May 21, 2014, at 6:02 PM, Ted Sariyski <tsariysk(a)craft-tech.com> >> wrote: >> >>> Memory limitations. With one large window all processes have to allocate memory for the objects they own as well as for objects assigned to other process. >>> >> Are we talking about the same thing here? I’m referring to an MPI_Win. What objects do processes need to keep track of? >> >> — Pavan >> >> _______________________________________________ >> discuss mailing list >> discuss(a)mpich.org >> >> To manage subscription options or unsubscribe: >> >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > 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] cannot execute binary file
by Yida Wang 22 May '14

22 May '14

Oh, that makes sense now. But could it work as Intel-MPI? That is, running in the host machine but can launch processes in MIC. Thanks, YW On Thu, May 22, 2014 at 10:40 AM, "Antonio J. Peña" <apenya(a)mcs.anl.gov>wrote: > > If you have compiled MPICH for the MIC, it'll only work on the MIC. That's > why mpich.hydra is not an executable on your host machine. ssh to the MIC > and try from there directly. > > Antonio > > > > On 05/21/2014 09:43 PM, Yida Wang wrote: > > Sure. Attached please find it. > > Thanks, > YW > > > On Wed, May 21, 2014 at 10:40 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > >> Could you send us your config.log in mpich directory? >> >> — >> Huiwei >> >> On May 21, 2014, at 9:20 PM, Yida Wang <yidawa(a)gmail.com> wrote: >> >> > No. But even using root, I will get the same error. >> > >> > >> > On Wed, May 21, 2014 at 10:19 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> >> wrote: >> > Looks like you have installed mpich under root. >> > Just to confirm, are you running mpiexec.hydra under root too? >> > — >> > Huiwei >> > >> > On May 21, 2014, at 9:14 PM, Yida Wang <yidawa(a)gmail.com> wrote: >> > >> > > 1. -rwxr-xr-x 1 root root 1460092 May 21 20:41 mpiexec.hydra >> > > 2. not a dynamic executable >> > > >> > > Thanks, >> > > YW >> > > >> > > >> > > On Wed, May 21, 2014 at 10:11 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> >> wrote: >> > > This looks more like a Linux problem rather than a MPICH problem. >> > > Could you give us the output of the following commands? >> > > 1. ls -la mpiexec.hydra >> > > 2. ldd -r mpiexec.hydra >> > > >> > > — >> > > Huiwei >> > > >> > > On May 21, 2014, at 8:53 PM, Yida Wang <yidawa(a)gmail.com> wrote: >> > > >> > > > The same error: >> > > > -bash: ./mpiexec.hydra: cannot execute binary file >> > > > >> > > > >> > > > On Wed, May 21, 2014 at 9:52 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> > > > You can go to the directory with mpiexec.hydra, and type >> ./mpiexec.hydra, to see what happens. >> > > > >> > > > --Junchao Zhang >> > > > >> > > > >> > > > On Wed, May 21, 2014 at 8:48 PM, Yida Wang <yidawa(a)gmail.com> >> wrote: >> > > > Linux xxx 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux >> > > > >> > > > >> > > > On Wed, May 21, 2014 at 9:46 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> > > > What is the output of "uname -a" on your machine? >> > > > >> > > > --Junchao Zhang >> > > > >> > > > >> > > > On Wed, May 21, 2014 at 8:05 PM, Yida Wang <yidawa(a)gmail.com> >> wrote: >> > > > Hi Guys, >> > > > >> > > > I just finished installing mpich. But when I tried to run it, it >> returned "cannot execute binary file". I double checked the file type by >> "file mpiexec.hydra", which got "mpiexec.hydra: ELF 64-bit LSB executable, >> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux >> 2.6.16, not stripped". I am running 64-bit CentOS. >> > > > >> > > > Any ideas of this error? >> > > > >> > > > Thanks, >> > > > YW >> > > > >> > > > _______________________________________________ >> > > > discuss mailing list discuss(a)mpich.org >> > > > To manage subscription options or unsubscribe: >> > > > https://lists.mpich.org/mailman/listinfo/discuss >> > > > >> > > > >> > > > _______________________________________________ >> > > > discuss mailing list discuss(a)mpich.org >> > > > To manage subscription options or unsubscribe: >> > > > https://lists.mpich.org/mailman/listinfo/discuss >> > > > >> > > > >> > > > _______________________________________________ >> > > > discuss mailing list discuss(a)mpich.org >> > > > To manage subscription options or unsubscribe: >> > > > https://lists.mpich.org/mailman/listinfo/discuss >> > > > >> > > > >> > > > _______________________________________________ >> > > > discuss mailing list discuss(a)mpich.org >> > > > To manage subscription options or unsubscribe: >> > > > https://lists.mpich.org/mailman/listinfo/discuss >> > > > >> > > > _______________________________________________ >> > > > discuss mailing list discuss(a)mpich.org >> > > > To manage subscription options or unsubscribe: >> > > > https://lists.mpich.org/mailman/listinfo/discuss >> > > >> > > _______________________________________________ >> > > discuss mailing list discuss(a)mpich.org >> > > To manage subscription options or unsubscribe: >> > > https://lists.mpich.org/mailman/listinfo/discuss >> > > >> > > _______________________________________________ >> > > discuss mailing list discuss(a)mpich.org >> > > To manage subscription options or unsubscribe: >> > > https://lists.mpich.org/mailman/listinfo/discuss >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > 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-4847apenya(a)mcs.anl.govwww.mcs.anl.gov/~apenya > > > _______________________________________________ > 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] Error: "MPIR_Get_contextid_sparse_group(1193): Too many communicators (0/2048)"
by Ted Sariyski 22 May '14

22 May '14

It is about MPI_win. Here is the problem as it relates to MPI (it is a Boltzmann type equation). There are N particles interacting with each other. Interaction is directional, so that a particle interacts only with those particles, which are within a narrow cone. The first step is to segregate the initial set of N particles into subsets of particles (I called it 'objects'), which interact with each other. Here is what I do: 1. Assign each object to a process. 2. The process which owns a object: * Makes a guess for the maximum number of particles expected in this object. * Allocates memory for it. * Opens a shared window. 3. All processes * Each particle identify which object it belongs to, and PUTs its data there. 4. After assembly is done, objects are passed to a solver. 5. Repeat What do you mean with: "Why canï¿½t all processes open one large window?" I guess I miss something. Thanks, --Ted On 05/21/2014 11:03 PM, Balaji, Pavan wrote: > On May 21, 2014, at 6:02 PM, Ted Sariyski <tsariysk(a)craft-tech.com> wrote: >> Memory limitations. With one large window all processes have to allocate memory for the objects they own as well as for objects assigned to other process. > Are we talking about the same thing here? Iï¿½m referring to an MPI_Win. What objects do processes need to keep track of? > > ï¿½ Pavan > > _______________________________________________ > 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] cannot execute binary file
by "Antonio J. Peña" 22 May '14

22 May '14

If you have compiled MPICH for the MIC, it'll only work on the MIC. That's why mpich.hydra is not an executable on your host machine. ssh to the MIC and try from there directly. Antonio On 05/21/2014 09:43 PM, Yida Wang wrote: > Sure. Attached please find it. > > Thanks, > YW > > > On Wed, May 21, 2014 at 10:40 PM, Lu, Huiwei <huiweilu(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > Could you send us your config.log in mpich directory? > > --- > Huiwei > > On May 21, 2014, at 9:20 PM, Yida Wang <yidawa(a)gmail.com > <mailto:[email protected]>> wrote: > > > No. But even using root, I will get the same error. > > > > > > On Wed, May 21, 2014 at 10:19 PM, Lu, Huiwei > <huiweilu(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > Looks like you have installed mpich under root. > > Just to confirm, are you running mpiexec.hydra under root too? > > --- > > Huiwei > > > > On May 21, 2014, at 9:14 PM, Yida Wang <yidawa(a)gmail.com > <mailto:[email protected]>> wrote: > > > > > 1. -rwxr-xr-x 1 root root 1460092 May 21 20:41 mpiexec.hydra > > > 2. not a dynamic executable > > > > > > Thanks, > > > YW > > > > > > > > > On Wed, May 21, 2014 at 10:11 PM, Lu, Huiwei > <huiweilu(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > > This looks more like a Linux problem rather than a MPICH problem. > > > Could you give us the output of the following commands? > > > 1. ls -la mpiexec.hydra > > > 2. ldd -r mpiexec.hydra > > > > > > --- > > > Huiwei > > > > > > On May 21, 2014, at 8:53 PM, Yida Wang <yidawa(a)gmail.com > <mailto:[email protected]>> wrote: > > > > > > > The same error: > > > > -bash: ./mpiexec.hydra: cannot execute binary file > > > > > > > > > > > > On Wed, May 21, 2014 at 9:52 PM, Junchao Zhang > <jczhang(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > > > You can go to the directory with mpiexec.hydra, and type > ./mpiexec.hydra, to see what happens. > > > > > > > > --Junchao Zhang > > > > > > > > > > > > On Wed, May 21, 2014 at 8:48 PM, Yida Wang <yidawa(a)gmail.com > <mailto:[email protected]>> wrote: > > > > Linux xxx 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 > 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > On Wed, May 21, 2014 at 9:46 PM, Junchao Zhang > <jczhang(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > > > What is the output of "uname -a" on your machine? > > > > > > > > --Junchao Zhang > > > > > > > > > > > > On Wed, May 21, 2014 at 8:05 PM, Yida Wang <yidawa(a)gmail.com > <mailto:[email protected]>> wrote: > > > > Hi Guys, > > > > > > > > I just finished installing mpich. But when I tried to run > it, it returned "cannot execute binary file". I double checked the > file type by "file mpiexec.hydra", which got "mpiexec.hydra: ELF > 64-bit LSB executable, version 1 (SYSV), dynamically linked (uses > shared libs), for GNU/Linux 2.6.16, not stripped". I am running > 64-bit CentOS. > > > > > > > > Any ideas of this error? > > > > > > > > Thanks, > > > > YW > > > > > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > <mailto:[email protected]> > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > _______________________________________________ > > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > > To manage subscription options or unsubscribe: > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > > _______________________________________________ > > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > > To manage subscription options or unsubscribe: > > > https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- 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

Re: [mpich-discuss] Very long configuration time
by William Gropp 22 May '14

22 May '14

We should look at this again. Many years ago, autoconf supported a local cache, but it didn't do it correctly - it would use the cache even when the cache values did not correspond to the environment. A common error was to use the cache even when configuring with a different compiler or compiler flags, thus picking up incorrect results. After several wasted days tracking down problems that were due to autoconf's broken cache system, we (that means I) added aclocal_cache.m4 to our local autoconf macros; this redefines AC_CACHE_LOAD. There are also routines to save and load the cache for subsidiary configure invocations. But that was a long, long time ago. Today's autoconf is vastly different and may be more robust in how it handles caching. Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On May 21, 2014, at 8:26 PM, Rob Latham wrote: > > > On 05/21/2014 03:35 PM, Yida Wang wrote: >> I have to use icc since I want to run code on Intel Xeon Phi. Also, I >> tried to install MPICH2 since it claims to support Intel-MIC >> architecture and is open source. > > long ago, autoconf used to support a local cache. sadly, that appears not to work, despite the continued presence of a --cache-file command line parameter. It was perfect for just these kinds of situations: for but one example, mpich looks for stdint.h twice. > > ==rob > >> >> BTW, still configuring. It's faster to do it locally (both the source >> code and the Intel compiler), but encountered a Fortran type length >> detection error (don't remember the exact error information now, it >> recommended me to "Consider setting CROSS_F77_SIZEOF_INTEGER to the >> length in bytes of a Fortran INTEGER") last run. > > >> >> Thanks, >> YW >> >> >> On Wed, May 21, 2014 at 4:28 PM, Jed Brown <jed(a)jedbrown.org >> <mailto:[email protected]>> wrote: >> >> Kenneth Raffenetti <raffenet(a)mcs.anl.gov >> <mailto:[email protected]>> writes: >> >> > The Intel compilers could also be a source of slowdown. Are they >> > installed on a network filesystem? They may also call out to a >> network >> > license server each time they are invoked for a compile test. >> Does just >> > compiling a small program take a long time with icc, ifort, etc.? >> >> The system headers and libraries are also often on a network file >> system. Although moving the source tree to a local disk usually >> provides some improvement, I rarely find it getting anywhere close to >> the performance of a cheap laptop because most of the file accesses >> performed by the compiler are hitting the network anyway. This is the >> price we all pay for legacy file system semantics and dumb compiler >> architecture. I think most companies in a place to change these things >> do full local installs on their development boxes so that compilation is >> fast. And the HPC vendors wear blindfolds and put their heads in the >> sand. >> >> As for Intel license servers, this is the price you pay for anti-piracy >> measures. People that are really ticked off by this crack their >> compilers---the pirates enjoy a better user experience. Is it ethical >> to use a cracked version if you've already paid for the licensed >> version? >> >> Besides those issues, the Intel compiler usually takes a lot longer to >> compile. It's worth building with gcc and clang to compare. You might >> be pleasantly surprised to find that in addition to compiling faster, >> your code also runs faster (this is the case for several applications I >> work with). >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0