- devel - mailman3.cels.anl.gov

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

17 May '14

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

Re: [mpich-devel] integration the MPICH2 into Visual studio 2010
by Lu, Huiwei 16 May '14

16 May '14

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

1 0

integration the MPICH2 into Visual studio 2010
by Chafik sanaa 15 May '14

15 May '14

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 ...

1 0

LinkedIn 가입 초대 메일
by seungkyun Lim 02 May '14

02 May '14

LinkedIn ------------ LinkedIn 1촌을 맺고 싶습니다. seungkyun 드림 seungkyun Lim 목원대학교 학생 대한민국 seungkyun Lim 님을 아시나요? 확인해 주세요. https://www.linkedin.com/e/21lby5-hup0szkb-38/isd/5867861760517615616/YOtoe… -- 현재 수신 희망 메일 설정에 따라 1촌 신청 메일을 회원님께 발송드리고 있습니다. 메일 수신을 원치 않으시면 여기를 클릭해 주세요. http://www.linkedin.com/e/21lby5-hup0szkb-38/XI_89wme9JmfEypxewQDpbla2L/goo… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043, USA.

1 0

Re: [mpich-devel] Suboptimal MPI_Allreduce() for intercommunicators
by Lisandro Dalcin 01 May '14

01 May '14

On 1 May 2014 16:53, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >>> (For example, on one side of the intercommunicator sendbuf=1 byte, recvbuf=1 gigabyte; on the other side, sendbuf=1 gigabyte, recvbuf=1 byte) >>> >> >> For Allreduce, you cannot have 1 byte/ 1gigabyte at each side. > > For intercommunicator collectives, one side gets the results from the other side. For allgather, it is specified that the communication can be of unequal amounts: MPI-3 pg 166, 9-15. I am assuming the same holds for allreduce, which just says "Both groups should provide count and datatype arguments that specify the same type signature." (188:23-24) > OK, you are right. After looking more closely to the code, I managed to write a patch and upload it to the trac ticket. I'm doing a memory allocation, but the original implementation also had to allocate memory at ranks 0 on left and right groups (look at MPIR_Reduce_inter() ) -- 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] Suboptimal MPI_Allreduce() for intercommunicators
by Rajeev Thakur 01 May '14

01 May '14

>> (For example, on one side of the intercommunicator sendbuf=1 byte, recvbuf=1 gigabyte; on the other side, sendbuf=1 gigabyte, recvbuf=1 byte) >> > > For Allreduce, you cannot have 1 byte/ 1gigabyte at each side. For intercommunicator collectives, one side gets the results from the other side. For allgather, it is specified that the communication can be of unequal amounts: MPI-3 pg 166, 9-15. I am assuming the same holds for allreduce, which just says "Both groups should provide count and datatype arguments that specify the same type signature." (188:23-24) Rajeev

1 0

Re: [mpich-devel] Suboptimal MPI_Allreduce() for intercommunicators
by Lisandro Dalcin 01 May '14

01 May '14

On 30 April 2014 18:56, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > It was probably done that way to avoid the need for memory allocation, but can you add a ticket in Trac and we will look at it. > https://trac.mpich.org/projects/mpich/ticket/2074 > > (For example, on one side of the intercommunicator sendbuf=1 byte, recvbuf=1 gigabyte; on the other side, sendbuf=1 gigabyte, recvbuf=1 byte) > For Allreduce, you cannot have 1 byte/ 1gigabyte at each side. -- 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] progress in flushall
by Balaji, Pavan 30 Apr '14

30 Apr '14

Jeff, On Apr 30, 2014, at 4:29 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > On Wed, Apr 30, 2014 at 3:58 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> On Apr 29, 2014, at 10:20 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> Yeah, I know that's what MPICH gives me. My point is that is >>> undesirable. All sync operations should make progress, no matter >>> what. >> >> They are not required to make progress from the spec perspective. It’s a bad assumption to make that Win_flush will always make progress. I think it’s OK for it to be mostly a no-op when there are no operations posted. If you need progress, why don’t you use test or something similar? > > I want flushall to make progress because there might be incoming RMA > that won't be processed otherwise. While today MPICH makes progress > on all Ch3 ops in Barrier, if that ever changes, ARMCI_Barrier is > going to deadlock because it does win_flush_all then mpi_barrier. I don’t think that’ll change. Barrier will need to make progress on RMA operations (unless the RMA operations are asynchronous) in order to remain compliant with the standard. The following program has to always work correctly: P0: MPI_Put MPI_Win_flush(_all) MPI_Barrier P1: MPI_Barrier The only case that’ll change is if we decide to somehow do async progress for all RMA operations (e.g., using a separate thread). But in that case, this entire problem wouldn’t exist anyway. > I'm already adding Iprobe for progress inside of ARMCI-MPI, but it > seems silly to have to test for p2p to get progress in RMA and for RMA > sync ops to not guarantee progress. I'd much prefer the design where > p2p and rma progress are decoupled and my RMA sync ops are burdened > with progress on p2p and vice versa. I’m not sure how you can reliably do that, in a standard compliant way. — Pavan

1 0

Re: [mpich-devel] progress in flushall
by Jeff Hammond 30 Apr '14

30 Apr '14

On Wed, Apr 30, 2014 at 3:58 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > On Apr 29, 2014, at 10:20 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> Yeah, I know that's what MPICH gives me. My point is that is >> undesirable. All sync operations should make progress, no matter >> what. > > They are not required to make progress from the spec perspective. It’s a bad assumption to make that Win_flush will always make progress. I think it’s OK for it to be mostly a no-op when there are no operations posted. If you need progress, why don’t you use test or something similar? I want flushall to make progress because there might be incoming RMA that won't be processed otherwise. While today MPICH makes progress on all Ch3 ops in Barrier, if that ever changes, ARMCI_Barrier is going to deadlock because it does win_flush_all then mpi_barrier. If flush_all doesn't process incoming RMA, the initiators cannot return from win_flush_all and will never proceed to barrier, while the processes that haven't initiated any RMA will be in mpi_barrier not make progress on RMA. If win_unlock_all behaves like win_flush_all and win_free doesn't make progress, then I can get the same deadlock scenario in ARMCI_Free. I'm already adding Iprobe for progress inside of ARMCI-MPI, but it seems silly to have to test for p2p to get progress in RMA and for RMA sync ops to not guarantee progress. I'd much prefer the design where p2p and rma progress are decoupled and my RMA sync ops are burdened with progress on p2p and vice versa. Best, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-devel] Suboptimal MPI_Allreduce() for intercommunicators
by Rajeev Thakur 30 Apr '14

30 Apr '14

It was probably done that way to avoid the need for memory allocation, but can you add a ticket in Trac and we will look at it. (For example, on one side of the intercommunicator sendbuf=1 byte, recvbuf=1 gigabyte; on the other side, sendbuf=1 gigabyte, recvbuf=1 byte) Rajeev On Apr 30, 2014, at 4:44 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > The implementation of Allreduce for intercommunicator > (MPIR_Allreduce_inter in src/mpi/coll/allreduce.c) uses more or less > the following algorithm (this is Python code I'm using to test this > issue) > > def allreduce_inter_mpich(obj, op, comm, tag, localcomm, low_group): > zero = 0 > if comm.rank == 0: > root = MPI.ROOT > else: > root = MPI.PROC_NULL > if low_group: > ignore = reduce_inter(obj, op, zero, comm, tag, localcomm) > result = reduce_inter(obj, op, root, comm, tag, localcomm) > else: > result = reduce_inter(obj, op, root, comm, tag, localcomm) > ignore = reduce_inter(obj, op, zero, comm, tag, localcomm) > return localcomm.bcast(result, 0) > > > However, while the broadcasts at each group overlap, the calls to > reduce_inter() introduce serialization. A much better implementation > would be: > > def allreduce_inter_dalcinl(obj, op, comm, tag, localcomm): > result = reduce_binomial(obj, op, 0, localcomm, tag) > if comm.rank == 0: > result = comm.sendrecv(result, 0, tag, None, 0, tag) > return localcomm.bcast(result, 0) > > i.e, perform (overlaped) reductions in the local groups, exchange > results between local and remote rank 0, and (overlaped) broadcast in > the local groups. > > I'm ataching a test Python script (I do not expect you to run it :-), > but perhaps you want to see the code). I'm defining a reduce operation > that artificially sleeps 1 second. Running this code in 8 cores in my > desktop clearly shows the issue with the MPICH implementation: > > $ mpiexec -n 8 python test-reduce.py > [mpich] time: min=4.003491e+00 max=4.003569e+00 > [dalcinl] time: min=2.002367e+00 max=2.002456e+00 > > What do you think? Am I right? Or perhaps I'm missing something obvious? > > > -- > 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 > <test-allreduce.py>_______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0