July 2013 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] mpi-forum.org website seems busted
by Jeff Squyres (jsquyres) 22 Jul '13

22 Jul '13

Yup -- checked it: [cid:[email protected]] On Jul 19, 2013, at 5:00 PM, Rob Latham <robl(a)mcs.anl.gov<mailto:[email protected]>> wrote: http://www.mpi-forum.org/ doesn't look right ... http://www.mpi-forum.org/docs/docs.html is a 404 But direct links to the PDFs are rendering ok: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] mpi-forum.org website seems busted
by William Gropp 22 Jul '13

22 Jul '13

Thanks. That tells me that www.mpi-forum.org is down for more than just me. MCS Systems, can you check this again? Thanks! Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jul 22, 2013, at 7:10 PM, Jeff Hammond wrote: > http://www.downforeveryoneorjustme.com/http://www.mpi-forum.org/ is a > good way to verify that circumvents possible local effects. > > Jeff > > On Mon, Jul 22, 2013 at 8:02 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com> wrote: >> Rajeev - >> >> I still cannot reach www.mpi-forum.org. >> >> Sent from my phone. No type good. >> >> On Jul 22, 2013, at 7:09 PM, "Rajeev Thakur" <thakur(a)mcs.anl.gov> wrote: >> >>> This has been fixed. >>> >>> Rajeev >>> >>> On Jul 19, 2013, at 4:00 PM, Rob Latham wrote: >>> >>>> http://www.mpi-forum.org/ doesn't look right ... >>>> >>>> http://www.mpi-forum.org/docs/docs.html is a 404 >>>> >>>> But direct links to the PDFs are rendering ok: >>>> http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf >>>> >>>> ==rob >>>> >>>> -- >>>> Rob Latham >>>> Mathematics and Computer Science Division >>>> Argonne National Lab, IL USA >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] mpi-forum.org website seems busted
by Jeff Hammond 22 Jul '13

22 Jul '13

http://www.downforeveryoneorjustme.com/http://www.mpi-forum.org/ is a good way to verify that circumvents possible local effects. Jeff On Mon, Jul 22, 2013 at 8:02 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Rajeev - > > I still cannot reach www.mpi-forum.org. > > Sent from my phone. No type good. > > On Jul 22, 2013, at 7:09 PM, "Rajeev Thakur" <thakur(a)mcs.anl.gov> wrote: > >> This has been fixed. >> >> Rajeev >> >> On Jul 19, 2013, at 4:00 PM, Rob Latham wrote: >> >>> http://www.mpi-forum.org/ doesn't look right ... >>> >>> http://www.mpi-forum.org/docs/docs.html is a 404 >>> >>> But direct links to the PDFs are rendering ok: >>> http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf >>> >>> ==rob >>> >>> -- >>> Rob Latham >>> Mathematics and Computer Science Division >>> Argonne National Lab, IL USA >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [Mpi-forum] mpi-forum.org website seems busted
by Jeff Squyres (jsquyres) 22 Jul '13

22 Jul '13

Rajeev - I still cannot reach www.mpi-forum.org. Sent from my phone. No type good. On Jul 22, 2013, at 7:09 PM, "Rajeev Thakur" <thakur(a)mcs.anl.gov> wrote: > This has been fixed. > > Rajeev > > On Jul 19, 2013, at 4:00 PM, Rob Latham wrote: > >> http://www.mpi-forum.org/ doesn't look right ... >> >> http://www.mpi-forum.org/docs/docs.html is a 404 >> >> But direct links to the PDFs are rendering ok: >> http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf >> >> ==rob >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] mpi-forum.org website seems busted
by Rajeev Thakur 22 Jul '13

22 Jul '13

This has been fixed. Rajeev On Jul 19, 2013, at 4:00 PM, Rob Latham wrote: > http://www.mpi-forum.org/ doesn't look right ... > > http://www.mpi-forum.org/docs/docs.html is a 404 > > But direct links to the PDFs are rendering ok: > http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

mpi-forum.org website seems busted
by Rob Latham 19 Jul '13

19 Jul '13

http://www.mpi-forum.org/ doesn't look right ... http://www.mpi-forum.org/docs/docs.html is a 404 But direct links to the PDFs are rendering ok: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [Mpi-forum] Ask for detail about MPI_Type_create_struct specification
by George Bosilca 18 Jul '13

18 Jul '13

The MPI standard is pretty clear about this. 1) MPI_Type_create is a local function, each process is freely allowed to call it with it's arguments. 2) the matching in MPI must have the same type signature (and not type map), thus the local displacement on the datatype is not significant. Feel free to read the Datatype chapter in MPI 3.0 for further information. George. On Jul 18, 2013, at 14:11 , Minh Quan HO <hmquan89(a)gmail.com> wrote: > Hello, > I'm working on HPL (High Performance Linpack) and I have a question about > MPI_Type_create_struct : > > int MPI_Type_struct( > int count, > int *array_of_blocklengths, > MPI_Aint *array_of_displacements, > MPI_Datatype *array_of_types, > MPI_Datatype *newtype > ) > > - Two processes A and B calls MPI_Type_create_struct with the same content of > 'count', 'array_of_blocklengths' and 'array_of_types', but maybe > *not* the same 'array_of_displacements' (due to private memory or > custom stride of send/recv buffer) > > - Example : > On process A : > count = 3 > dispA[0] = 0 - blen[0] = 1 - type[0] = MPI_INT => block0 > dispA[1] = 16 - blen[1] = 2 - type[1] = MPI_DOUBLE => block1 > dispA[2] = 2014 - blen[2] = 4 - type[2] = MPI_DOUBLE => block2 > > On process B : > count = 3 > dispB[0] = 8 - blen[0] = 1 - type[0] = MPI_INT > dispB[1] = 24 - blen[1] = 2 - type[1] = MPI_DOUBLE > dispB[2] = 128 - blen[2] = 4 - type[2] = MPI_DOUBLE > > - The question is : According to MPI, is this possible that two > processes calls this MPI routine with their own different > displacements ? (like example above - and also what HPL does) > > - If yes, at Receiver side, I suppose that further send/recv with > this type will do : > block0 from A at dispA[0] must be written to B on dispB[0] > block1 from A at dispA[1] must be written to B on dispB[1] > and block2 from A at dispA[2] must be written to B on dispB[2], > aren't they ? > > Thank you for any response, > > Quan > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Ask for detail about MPI_Type_create_struct specification
by Minh Quan HO 18 Jul '13

18 Jul '13

Hello, I'm working on HPL (High Performance Linpack) and I have a question about MPI_Type_create_struct : int MPI_Type_struct( int count, int *array_of_blocklengths, MPI_Aint *array_of_displacements, MPI_Datatype *array_of_types, MPI_Datatype *newtype ) - Two processes A and B calls MPI_Type_create_struct with the same content of 'count', 'array_of_blocklengths' and 'array_of_types', but maybe *not* the same 'array_of_displacements' (due to private memory or custom stride of send/recv buffer) - Example : On process A : count = 3 dispA[0] = 0 - blen[0] = 1 - type[0] = MPI_INT => block0 dispA[1] = 16 - blen[1] = 2 - type[1] = MPI_DOUBLE => block1 dispA[2] = 2014 - blen[2] = 4 - type[2] = MPI_DOUBLE => block2 On process B : count = 3 dispB[0] = 8 - blen[0] = 1 - type[0] = MPI_INT dispB[1] = 24 - blen[1] = 2 - type[1] = MPI_DOUBLE dispB[2] = 128 - blen[2] = 4 - type[2] = MPI_DOUBLE - The question is : According to MPI, is this possible that two processes calls this MPI routine with their own different displacements ? (like example above - and also what HPL does) - If yes, at Receiver side, I suppose that further send/recv with this type will do : block0 from A at dispA[0] must be written to B on dispB[0] block1 from A at dispA[1] must be written to B on dispB[1] and block2 from A at dispA[2] must be written to B on dispB[2], aren't they ? Thank you for any response, Quan

1 0

Re: [Mpi-forum] MPI Ain't and MPI 3.1
by N.M. Maclaren 17 Jul '13

17 Jul '13

On Jul 17 2013, Jim Dinan wrote: > >I've just gotten around to updating the ticket with feedback from the June >meeting. My apologies, the ticket was way out of sync with the progress on >this issue. I'm hopeful that the new proposal text addresses your concerns >with respect to segmented and tagged architectures: > >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 Thanks. >The solution you described is similar to "proposed solution #2" on the >ticket, which won't work for Fortran, because Fortran lacks the unsigned >integers we would need for the MPI_Disp type. Not really. I wasn't addressing that point - not least because I regard C unsigned types as an abomination. The key point was a handle to identify the window, for the reasons that David Goodell describes (though I gave some of the underlying ones rather than the standardese). The signed/unsigned distinction is a red herring because (for those reasons) integer arithmetic on even uintptr_t is not guaranteed to work in the way that I think you expect. All that the standard requires is that it can be converted to and from a pointer without losing the address. The point is that an address is inherently a combination of a handle and an integer. The handle can be ignored for flat memory architectures, but not all are like that, and it is quite likely that we will see structured ones return in not too long from now. How likely? My guess is perhaps a 30% chance within a decade. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] MPI_Win_lock_all() ordering question
by Jim Dinan 17 Jul '13

17 Jul '13

Yes and no. That ticket is calling out a potential starvation issue, whereas the issue you raised is deadlock. There is no way to solve the deadlock issue through prioritization, since there could be an unbounded delay between your two calls to MPI_Win_lock and you can't prioritize a request you haven't received. The deadlock issue could be resolved by requiring that all locks in MPI_Win_lock_all are obtained atomically, but this would be an unreasonable restriction on implementations. Torsten Hoefler published a paper that uses this approach by creating a single global lock, but this has a negative impact on conventional lock/unlock. The implementation I wrote for MPICH requests the shared lock at each process lazily, as needed, and you can certainly deadlock it as you described. ~Jim. On Wed, Jul 17, 2013 at 12:04 PM, Michael Raymond <mraymond(a)sgi.com> wrote: > Thanks. Searching the tickets just now, I found #363. Are my issue and > that ticket related? > > https://svn.mpi-forum.org/**trac/mpi-forum-web/ticket/363<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/363> > > > On 07/17/2013 10:54 AM, Jim Dinan wrote: > >> Hi Michael, >> >> This believe that this can deadlock. I agree that it's unfortunate that >> we didn't call it out in the spec, given that it would help to clarify >> the intended semantics. >> >> ~Jim. >> >> >> On Wed, Jul 17, 2013 at 11:41 AM, Michael Raymond <mraymond(a)sgi.com >> <mailto:[email protected]>> wrote: >> >> I've got a question about the use of MPI_Win_lock_all() in the >> face of competing MPI_Win_lock(EXCLUSIVE) calls. Consider the >> following calls sequence: >> >> >> 0 1 >> MPI_Win_lock(EXCLUSIVE, 0) >> >> MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all() >> >> .... .... >> MPI_Win_unlock(1) MPI_Win_unlock_all() >> MPI_Win_unlock(0) >> >> In this situation 0 has an exclusive lock on itself. >> Simultaneously, 0 tries to get 1 exclusively and 1 tries to get a >> shared lock on everyone. If 0 gets lucky, it will get to go first >> and everything will go fine. If OTOH 1 locks itself shared and then >> tries to lock 0 shared, deadlock ensues. You could argue that there >> should be some global queue / governor that lets 0 go first, but >> then I could see running into scalability problems. >> >> I can't find any place in the standard that says if the user >> shouldn't do this, or if deadlock is allowed, or if the MPI >> implementation should figure things out on its own. Thoughts? >> >> -- >> Michael A. Raymond >> SGI MPT Team Leader >> (651) 683-3434 >> >> ______________________________**___________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]**forum.org<mpi-forum(a)lists.mpi-forum.org> >> > >> http://lists.mpi-forum.org/__**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/__mailman/listinfo.cgi/mpi-forum> >> <http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >> **> >> >> >> >> >> >> ______________________________**_________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >> >> > -- > Michael A. Raymond > SGI MPT Team Leader > (651) 683-3434 > >

1 0