- devel - mailman3.cels.anl.gov

Re: [mpich-devel] MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Jeff Hammond 22 Sep '14

22 Sep '14

PAMID_COLLECTIVES=0 is really bad for performance. IBM should figure out a way to disable it on a per-communicator basis when MPI_COMM_SPLIT is going to have issues. I recall they allow one to "unoptimize" a communicator but I thought that was only possible after it was created. Jeff On Mon, Sep 22, 2014 at 8:39 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Sam, > I had some updates from IBM last week. They reproduced the problem and > found it only happens when the number of MPI ranks is non-power-of-2. Their > advice is that since the IBM BG/Q optimized collectives themselves are > mostly designed only to be helpful for blocks with power-of-2 geometries, > you can try in your program to see if subsequent collective calls with > PAMID_COLLECTIVES=1 are actually faster than PAMID_COLLECTIVES=0 on comms > with a non-power-of-2 geometry. If the answer is no, then you can just run > with PAMID_COLLECTIVES=0 and avoid the dup/split performance issue. > Otherwise, IBM may prioritize this ticket. > > Thanks. > --Junchao Zhang > > On Thu, Jul 3, 2014 at 4:41 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> >> Hi, Sam, >> I wrote micro-benchmarks for MPI_Comm_split/dup. My profiling results >> suggested the problem lies in a IBM PAMI library call, >> PAMI_Geometry_create_taskrange(). Unfortunately, I don't have access to the >> PAMI source code and don't know why. I reported it to IBM and hope IBM will >> fix it. >> Alternatively, you can set an environment variable PAMID_COLLECTIVES=0 >> to disables pami collectives. My tests showed it at least fixed the >> scalability problem of Comm_split and Comm_dup. >> Also through profiling, I found the qsort() called in MPICH code is >> actually using the merge sort algorithm in Mira's libc library. >> >> >> >> --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 >> >> > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Sam Williams 22 Sep '14

22 Sep '14

All of Mira (48k) is technically not a power of two. I tried the pami option at one point. I don't recall it giving better performance - Sam > On Sep 22, 2014, at 8:39 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > Sam, > I had some updates from IBM last week. They reproduced the problem and found it only happens when the number of MPI ranks is non-power-of-2. Their advice is that since the IBM BG/Q optimized collectives themselves are mostly designed only to be helpful for blocks with power-of-2 geometries, you can try in your program to see if subsequent collective calls with PAMID_COLLECTIVES=1 are actually faster than PAMID_COLLECTIVES=0 on comms with a non-power-of-2 geometry. If the answer is no, then you can just run with PAMID_COLLECTIVES=0 and avoid the dup/split performance issue. Otherwise, IBM may prioritize this ticket. > > Thanks. > --Junchao Zhang > >> On Thu, Jul 3, 2014 at 4:41 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> Hi, Sam, >> I wrote micro-benchmarks for MPI_Comm_split/dup. My profiling results suggested the problem lies in a IBM PAMI library call, PAMI_Geometry_create_taskrange(). Unfortunately, I don't have access to the PAMI source code and don't know why. I reported it to IBM and hope IBM will fix it. >> Alternatively, you can set an environment variable PAMID_COLLECTIVES=0 to disables pami collectives. My tests showed it at least fixed the scalability problem of Comm_split and Comm_dup. >> Also through profiling, I found the qsort() called in MPICH code is actually using the merge sort algorithm in Mira's libc library. >> >> >> >> --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] MPI_Comm_Split/Dup scalability on BGQ and K supercomputers
by Junchao Zhang 22 Sep '14

22 Sep '14

Sam, I had some updates from IBM last week. They reproduced the problem and found it only happens when the number of MPI ranks is non-power-of-2. Their advice is that since the IBM BG/Q optimized collectives themselves are mostly designed only to be helpful for blocks with power-of-2 geometries, you can try in your program to see if subsequent collective calls with PAMID_COLLECTIVES=1 are actually faster than PAMID_COLLECTIVES=0 on comms with a non-power-of-2 geometry. If the answer is no, then you can just run with PAMID_COLLECTIVES=0 and avoid the dup/split performance issue. Otherwise, IBM may prioritize this ticket. Thanks. --Junchao Zhang On Thu, Jul 3, 2014 at 4:41 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hi, Sam, > I wrote micro-benchmarks for MPI_Comm_split/dup. My profiling results > suggested the problem lies in a IBM PAMI library call, > PAMI_Geometry_create_taskrange(). Unfortunately, I don't have access to > the PAMI source code and don't know why. I reported it to IBM and hope IBM > will fix it. > Alternatively, you can set an environment variable PAMID_COLLECTIVES=0 > to disables pami collectives. My tests showed it at least fixed the > scalability problem of Comm_split and Comm_dup. > Also through profiling, I found the qsort() called in MPICH code is > actually using the merge sort algorithm in Mira's libc library. > > > > --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] mpich2 version (1.1.1p1) - download
by Rob Latham 26 Aug '14

26 Aug '14

On 08/26/2014 08:47 AM, Junchao Zhang wrote: > I checked the "Changes in 1.1.1p1" section in CHANGES, and found > tickets mentioned there are in the trac system, e.g., > https://trac.mpich.org/projects/mpich/ticket/744 > I think if you want, you can recover all changes made to that release > from mpich git log. there are 6118 changes on master between v1.1b1..HEAD. finding "just the bug fixes" is going to be a lot of work. You might want to consider rebasing your local modifications onto something more recent. ==rob > > > --Junchao Zhang > > > On Tue, Aug 26, 2014 at 6:48 AM, wesley(a)wesbland.com > <mailto:[email protected]> <wbland(a)anl.gov <mailto:[email protected]>> wrote: > > That release is very very old, so I doubt that those bugs were in > the bug tracking system that we use now. > > > Most likely, the best you'll be able to find is to look at the > release notes for that version and newer versions, but you probably > won't be able to find much about individual bugs that far back. > > > Wesley > > > > On Tue, Aug 26, 2014 at 6:55 AM, Damodara, Madhavi (GE Healthcare) > <Madhavi.Damodara(a)ge.com <mailto:[email protected]>> wrote: > > Thank you. > > May I know where are the bugs for this release are documented? > > Thanks, > Madhavi > -----Original Message----- > From: devel-bounces(a)mpich.org <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Rajeev Thakur > Sent: Monday, August 25, 2014 9:44 PM > To: devel(a)mpich.org <mailto:[email protected]> > Subject: Re: [mpich-devel] mpich2 version (1.1.1p1) - download > > It is working now. > > Rajeev > > > On Aug 25, 2014, at 6:57 AM, "Damodara, Madhavi (GE Healthcare)" > <Madhavi.Damodara(a)ge.com <mailto:[email protected]>> wrote: > > > Hi, > > > > We use mpich2 version 1.1.1p1 and want to download this from > > https://www.mpich.org/downloads/ as shown below as circle But > below link doesn't work and the page couldn't be opened. > > > > Can you please help us download the older version mpich2 > version 1.1.1p1? > > > > > > <image001.png><image002.jpg> > > > > Thanks, > > Madhavi > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] mpich2 version (1.1.1p1) - download
by Junchao Zhang 26 Aug '14

26 Aug '14

I checked the "Changes in 1.1.1p1" section in CHANGES, and found tickets mentioned there are in the trac system, e.g., https://trac.mpich.org/projects/mpich/ticket/744 I think if you want, you can recover all changes made to that release from mpich git log. --Junchao Zhang On Tue, Aug 26, 2014 at 6:48 AM, wesley(a)wesbland.com <wbland(a)anl.gov> wrote: > That release is very very old, so I doubt that those bugs were in the bug > tracking system that we use now. > > > Most likely, the best you'll be able to find is to look at the release > notes for that version and newer versions, but you probably won't be able > to find much about individual bugs that far back. > > > Wesley > > > On Tue, Aug 26, 2014 at 6:55 AM, Damodara, Madhavi (GE Healthcare) < > Madhavi.Damodara(a)ge.com> wrote: > >> Thank you. >> >> May I know where are the bugs for this release are documented? >> >> Thanks, >> Madhavi >> -----Original Message----- >> From: devel-bounces(a)mpich.org [mailto:[email protected]] On Behalf >> Of Rajeev Thakur >> Sent: Monday, August 25, 2014 9:44 PM >> To: devel(a)mpich.org >> Subject: Re: [mpich-devel] mpich2 version (1.1.1p1) - download >> >> It is working now. >> >> Rajeev >> >> On Aug 25, 2014, at 6:57 AM, "Damodara, Madhavi (GE Healthcare)" < >> Madhavi.Damodara(a)ge.com> wrote: >> >> > Hi, >> > >> > We use mpich2 version 1.1.1p1 and want to download this from >> > https://www.mpich.org/downloads/ as shown below as circle But below >> link doesn't work and the page couldn't be opened. >> > >> > Can you please help us download the older version mpich2 version >> 1.1.1p1? >> > >> > >> > <image001.png><image002.jpg> >> > >> > Thanks, >> > Madhavi >> > _______________________________________________ >> > 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 >> >> > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] mpich2 version (1.1.1p1) - download
by wesley＠wesbland.com 26 Aug '14

26 Aug '14

That release is very very old, so I doubt that those bugs were in the bug tracking system that we use now. Most likely, the best you'll be able to find is to look at the release notes for that version and newer versions, but you probably won't be able to find much about individual bugs that far back. Wesley On Tue, Aug 26, 2014 at 6:55 AM, Damodara, Madhavi (GE Healthcare) <Madhavi.Damodara(a)ge.com> wrote: > Thank you. > May I know where are the bugs for this release are documented? > Thanks, > Madhavi > -----Original Message----- > From: devel-bounces(a)mpich.org [mailto:[email protected]] On Behalf Of Rajeev Thakur > Sent: Monday, August 25, 2014 9:44 PM > To: devel(a)mpich.org > Subject: Re: [mpich-devel] mpich2 version (1.1.1p1) - download > It is working now. > Rajeev > On Aug 25, 2014, at 6:57 AM, "Damodara, Madhavi (GE Healthcare)" <Madhavi.Damodara(a)ge.com> wrote: >> Hi, >> >> We use mpich2 version 1.1.1p1 and want to download this from >> https://www.mpich.org/downloads/ as shown below as circle But below link doesn't work and the page couldn't be opened. >> >> Can you please help us download the older version mpich2 version 1.1.1p1? >> >> >> <image001.png><image002.jpg> >> >> Thanks, >> Madhavi >> _______________________________________________ >> 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

1 0

Re: [mpich-devel] mpich2 version (1.1.1p1) - download
by Damodara, Madhavi (GE Healthcare) 26 Aug '14

26 Aug '14

Thank you. May I know where are the bugs for this release are documented? Thanks, Madhavi -----Original Message----- From: devel-bounces(a)mpich.org [mailto:[email protected]] On Behalf Of Rajeev Thakur Sent: Monday, August 25, 2014 9:44 PM To: devel(a)mpich.org Subject: Re: [mpich-devel] mpich2 version (1.1.1p1) - download It is working now. Rajeev On Aug 25, 2014, at 6:57 AM, "Damodara, Madhavi (GE Healthcare)" <Madhavi.Damodara(a)ge.com> wrote: > Hi, > > We use mpich2 version 1.1.1p1 and want to download this from > https://www.mpich.org/downloads/ as shown below as circle But below link doesn't work and the page couldn't be opened. > > Can you please help us download the older version mpich2 version 1.1.1p1? > > > <image001.png><image002.jpg> > > Thanks, > Madhavi > _______________________________________________ > 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] mpich2 version (1.1.1p1) - download
by Rajeev Thakur 25 Aug '14

25 Aug '14

It is working now. Rajeev On Aug 25, 2014, at 6:57 AM, "Damodara, Madhavi (GE Healthcare)" <Madhavi.Damodara(a)ge.com> wrote: > Hi, > > We use mpich2 version 1.1.1p1 and want to download this from https://www.mpich.org/downloads/ as shown below as circle > But below link doesn’t work and the page couldn’t be opened. > > Can you please help us download the older version mpich2 version 1.1.1p1? > > > <image001.png><image002.jpg> > > Thanks, > Madhavi > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

mpich2 version (1.1.1p1) - download
by Damodara, Madhavi (GE Healthcare) 25 Aug '14

25 Aug '14

Hi, We use mpich2 version 1.1.1p1 and want to download this from https://www.mpich.org/downloads/ as shown below as circle But below link doesn't work and the page couldn't be opened. Can you please help us download the older version mpich2 version 1.1.1p1? [cid:[email protected]][cid:[email protected]] Thanks, Madhavi

1 0

Re: [mpich-devel] [mpich-discuss] MPICH make clean requires sudo and mucks with DESTDIR
by Dave Goodell (dgoodell) 22 Aug '14

22 Aug '14

Right, the "rm -f" should have been added back to a (new) "uninstall-local" target instead of the "clean-local" target. Obviously someone should verify my claims and test the actual fix. For obvious reasons, I'm not really in a position to spend any time writing and testing general MPICH patches. -Dave On Aug 22, 2014, at 3:53 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > > Thanks. The “uninstall-local” target is where the “rm -f” should have been? > > — Pavan > > On Aug 22, 2014, at 1:14 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > >> For whoever fixes this, this is the relevant bit of the Automake manual that talks about the "-local" targets: >> >> http://www.gnu.org/software/automake/manual/automake.html#Extending >> >> -Dave >> >> Begin forwarded message: >> >>> From: "Dave Goodell (dgoodell)" <dgoodell(a)cisco.com> >>> Subject: Re: [mpich-discuss] MPICH make clean requires sudo and mucks with DESTDIR >>> Date: August 22, 2014 1:11:18 PM CDT >>> To: "<discuss(a)mpich.org>" <discuss(a)mpich.org> >>> Cc: Jed Brown <jed(a)jedbrown.org>, Satish Balay <balay(a)mcs.anl.gov> >>> >>> On Aug 21, 2014, at 8:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>>> >>>> In the root Makefile is >>>> >>>> # we can only have one clean-local, so we hook into it via conditionally >>>> # defined variables in the dependencies section >>>> clean-local: $(CLEAN_LOCAL_TARGETS) >>>> rm -f ${DESTDIR}${bindir}/mpic++ >>> >>> I was curious if that was my fault as part of the build system rewrite, so I took a peek at his. It looks like a bug from Pavan's commit in June 2012: http://git.mpich.org/mpich.git/commitdiff/cd88cf96 >>> >>> The commit he references in his commit was the build system overhaul: http://git.mpich.org/mpich.git/commit/4153c8f8680eeb09a80424f2cc787e799e804… >>> >>> This is the relevant Makefile.sm that was present at the time of the overhaul: http://git.mpich.org/mpich.git/blob/5283393cd41ab38548477ef967f4205539d8e53… >>> >>> It has this "rm -f" in a (simplemake-specific) "uninstall-postamble" target, which is rather different from a "clean-local" target. This logic should probably be moved to an "uninstall-local" target instead. I'm in favor adding an UNINSTALL_LOCAL_TARGETS parallel to the CLEAN_LOCAL_TARGETS pattern already in use, but that's a decision for the MPICH guys to make. >>> >>>> I do not see how this could be correct, since >>>> >>>> 1) mucking with DESTDIR would require sudo for some configurations and make clean shouldn’t require sudo >>>> >>>> 2) should make clean muck with DESTDIR anyways? >>>> >>>> When I run make clean after a make install I do get an permissions error in trying to remove that link. >>> >>> I agree, it is not correct. >>> >>> -Dave >>> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0