August 2012 - mpiwg-rma - mailman3.cels.anl.gov

[Mpi3-rma] Target displacement sign issue
by Jim Dinan 28 Aug '12

28 Aug '12

Hi All, Currently, target displacements in put/get/acc/etc are defined to be non-negative integers of type, MPI_Aint. MPI_Aint is defined to be a signed integer. However, displacements associated with dynamic windows are addresses (unsigned) and can range into the space of negative integers. It seems like the least impact change would be to add a special case that the displacement argument will be interpreted as unsigned for dynamic windows. Changing the interface to take an 'unsigned MPI_Aint' would be the most clear (and preserve the existing and intended new semantics), but would break backward compatibility. Interested to hear your thoughts. ~Jim.

1 0

Re: [Mpi3-rma] Fwd: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 4]
by Jim Dinan 27 Aug '12

27 Aug '12

Hi Bill, As you apply these edits, could you filter out the feedback that should be discussed by the working group? Thanks, ~Jim. On 8/23/12 4:55 PM, William Gropp wrote: > For those of you not on the mpi-comments list, we have been receiving a > very detailed set of comments from Jeremiah Willcock. He's made it to > the RMA chapter (#11); this message also include chapter 12. Please > share comments on these; for the obvious typos, I as chapter author will > repair them as ticket-0 changes. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > Begin forwarded message: > >> *From: *Jeremiah Willcock <jewillco(a)osl.iu.edu >> <mailto:[email protected]>> >> *Subject: **[Mpi-comments] Comments on MPI 3.0 draft 2 [part 4]* >> *Date: *August 23, 2012 4:45:03 PM CDT >> *To: *<mpi-comments(a)mpi-forum.org <mailto:[email protected]>> >> *Reply-To: *Comments on the MPI Standard >> <mpi-comments(a)lists.mpi-forum.org >> <mailto:[email protected]>> >> >> These are in reference to the draft at >> <URL:http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf>. Thank you for >> considering them. >> >> -- Jeremiah Willcock >> >> Chapter 11: >> >> Why are the request-based one-sided functions named MPI_R* rather than >> MPI_I* like nonblocking point-to-point and collective functions? >> >> There are no request-based versions of fetch-and-op or compare-and-swap. >> >> Page 403 line 31: Add a comma after the second capital "B". >> >> Page 403 line 34: The semicolon here can be changed to a comma, and >> probably removed entirely. >> >> Page 404 line 15: "distributed memory" should be hyphenated. >> >> Page 404 line 22: The first comma should be a colon. >> >> Page 404 line 23: There should be a comma after "MPI_WIN_ALLOCATE_SHARED". >> >> Page 404 line 25: There is extra space around "to specify". >> >> Page 404 line 30: Should MPI be in sans-serif font? >> >> Page 405 line 24: Remove "and C++". >> >> Page 405 line 32: "address sized" should be hyphenated. >> >> Page 405 lines 42-43; page 408, lines 26-27; page 409, line 47: Which >> of these info keys must be set consistently between different processes? >> >> Page 406 lines 4-9: Can accumulate_ops be validly and portably set to >> anything other than the two values listed there? >> >> Page 406 line 17: There should be a comma after "units". >> >> Page 406 lines 42-43: "implementation specific" should be hyphenated. >> >> Page 409 line 44: The function name on the next line looks like it >> might fit on this one. >> >> Page 411 lines 4-5: Window flavors have not yet been introduced. In >> particular, the allocation functions should probably say which flavor >> of window they each produce. >> >> Page 411 lines 7-8: Some of these argument names might need to be in >> sans-serif. >> >> Page 411 lines 30-: "RMA" was written in sans-serif earlier in the >> chapter. >> >> Page 412 line 34: "MPI" should be in sans-serif. >> >> Page 413 line 21: "win" should be in sans-serif. >> >> Page 413 lines 21-22: Can the same memory be attached to different >> windows, just not the same window? >> >> Page 414 line 25: The "should" might need to be "must" to avoid issues >> similar to <URL:https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=495>. >> >> Page 415 line 12: "called" should be "call". >> >> Page 416 line 6: There should be commas after "disp_unit" and >> "create_kind". >> >> Page 416 line 20: There should be a comma after "returned". What if >> the user modifies the pointees of the pointers that are the values of >> these attributes in C? >> >> Page 416 line 28: Why return the group rather than the communicator >> itself? The group returned is listed as a "duplicate" -- does that >> mean the user is responsible for freeing it? >> >> Page 417 line 2: "MPI" should be in sans-serif. >> >> Page 417 line 12: "this" should be "the". >> >> Page 418 line 17: There should be a comma after "MPI_RGET_ACCUMULATE". >> >> Page 418 line 27: Make sure to note that "locally completed" does not >> mean the same thing as "completed" (I think). Will those be defined >> in detail later? >> >> Page 418 line 30: There should be a comma after "get call". >> >> Page 418 line 35: "; namely," can be changed to just a colon. >> >> Page 418 line 36: Which calls count as "accumulate calls"? >> >> Page 420 line 2: There should be a comma after "origin node". >> >> Page 420 line 31: "shared memory" should be hyphenated. >> >> Page 420 line 40: "occurred" should be "occurs". >> >> Page 422 line 7: There should be a comma after "B". >> >> Page 423 lines 31 and 37, page 424 lines 18 and 24: Would it be >> helpful to users to show the correct hints ("assert" arguments) to use >> in MPI_WIN_FENCE to express each fence's semantics to the implementation? >> >> Page 423 line 47: The example header should be on the same page as the >> example text. >> >> Page 424 line 33: I think "contribution" should be "contributions". >> >> Page 425 line 40: There should be a comma after "origin_count". >> >> Page 426 lines 9-11: Is there a valid reason that MPI_REPLACE (and >> MPI_NO_OP) are not allowed for MPI_REDUCE? They are not useful, most >> likely, but orthogonality seems to suggest that they be allowed anyway. >> >> Page 426 line 18: There should be a comma after "B". >> >> Page 426 line 46: Remove "then". >> >> Page 428 line 15: There is a line break (and thus probably a space in >> the source code) after the left parenthesis here. >> >> Page 428 line 26: "and MPI_NO_OP or" should be "MPI_NO_OP, or". >> >> Page 429: Is there a reason that there is not a similar special-case >> version of MPI_ACCUMULATE? >> >> Page 430: What happens if an MPI implementation does not support, for >> example, compare-and-swap on MPI_INTEGER16 values? >> >> Page 430 line 21: Please put compare_addr as its own variable >> declaration to avoid a line break between two variables. >> >> Page 430 line 48: "passive-target epoch" has not been defined yet as >> far as I know, and this use of the term does not reference a definition. >> >> Page 431 line 10: There should be a comma after "MPI_WIN_FLUSH_LOCAL". >> >> Page 432 line 15: There should be a comma after "MPI_WIN_UNLOCK". >> >> Page 433: Is it possible/likely that an rget does not complete locally >> until after a flush, fence, or similar call? That might be worth >> mentioning if true. >> >> Page 436 lines 24-25: "RMA" here should be in sans-serif (plus italic). >> >> Page 436 lines 26-34: This seems to imply sequential consistency >> between get and put accesses on the same window, even if they are not >> consistent with loads and stores? Or is that issue removed by the >> rules about overlapping get and put accesses in the same epoch? >> >> Page 436 lines 35-39: Can different processes see the updates in a >> different order (than each other's view of them, not just from the >> order the updates actually occurred)? >> >> Page 437: "passive target" and "active target" should be hyphenated. >> >> Page 437 line 19: "shared memory" should be hyphenated. >> >> Page 438 line 7: There should be a comma after "MPI_WIN_POST". >> >> Page 441: Does MPI_WIN_FENCE start and/or end active-target or >> passive-target epochs? This is answered on page 438, but the answer >> should be here as well. >> >> Page 443 line 13: There should be a space between the comma and "win". >> >> Page 443 line 22: "occurred" should be "occurs". >> >> Page 443 line 25: Insert "has" before "called". >> >> Does it make sense to have a nonblocking version of MPI_WIN_START? >> What about MPI_WIN_FENCE or the other synchronization calls that >> could block (MPI_WIN_WAIT already has a nonblocking version, although >> it does not use an MPI_Request). >> >> Page 445 line 21: "call" should be "calls". >> >> Page 445 lines 25 and 31: The "no need to wait" part is not a complete >> sentence. >> >> Page 445 lines 24-34: "initiate" should be either "initiates" or >> capitalized in each of these. >> >> Page 446 line 2: The tuple representing the graph should probably use >> \langle and \rangle rather than < and >; this will probably fix the >> spacing around them as well. >> >> Page 446 lines 6 and 10: "group" in each of these lines might need to >> be sans-serif. >> >> Page 447 line 48: There is extra space before "load". >> >> Page 448 line 1: "call" should be "calls". >> >> Page 448 line 3: "lock protected" should be hyphenated. >> >> Page 450 lines 16-18: How does this affect whether rget, rput, ... >> accesses have "locally completed"? Is this sentence true about those >> kinds of accesses until MPI_Wait is called on them? Is MPI_Wait on >> such a request guaranteed not to block after MPI_WIN_FLUSH_LOCAL returns? >> >> Page 450 line 46: "copy" should be "copies"? >> >> Page 451 line 15: "implementation" should be "implementation's". >> >> Page 451 line 17: "assertion specific" should be hyphenated. >> >> Page 451 line 25: There should be a comma after "MPI_MODE_NOPRECEDE". >> >> Page 452 lines 1 and 9: There is extra space before "stores" on each >> of these lines. >> >> Page 452 line 22: There should be a comma after "acquire". >> >> Page 452 line 32: "argument" should be "arguments". >> >> Page 452 line 43: "comm" should be in sans-serif. >> >> Page 453 lines 33-36: Is this text defining "complete", or just >> repeating a definition stated officially elsewhere? If it is the >> definition, the wording doesn't make that obvious. >> >> Page 454 lines 14 and 21: "becomes visible" means "becomes visible >> eventually" (in an implementation-defined amount of time); that may be >> worth stating explicitly here. >> >> Page 454 line 18: There is a space missing before "MPI_WIN_LOCK". >> >> Page 454 line 29: Insert "a" or "the" before "private". Which process >> does "the process memory" refer to? >> >> Page 454 lines 35-36: What is the motivation for putting "even" before >> "flush"? >> >> Page 454 line 47: This needs to be qualified with "within the same >> access epoch" or similar, like the next sentence is. >> >> Page 455 line 4: "MPI" should be sans-serif. >> >> Page 455 lines 26 and 29: Does "update" mean remote update here? >> >> Page 456 line 1: "will" should be "would". >> >> Page 456 line 18: "a remote process" should be plural. >> >> Page 456 line 23: "magnitude" should be "magnitudes". >> >> Page 456 line 38: There is extra space before "updates". >> >> Page 456 line 41: Add "elsewhere" before "in". >> >> Page 456 line 45: Remove "in the case". >> >> Page 457 line 14: There is extra space before "stores". >> >> Page 457 line 20: Should "being posted" be "posted" instead? The >> comma after "posted" can be removed. >> >> Page 457 line 47: "implementation dependent" should be hyphenated. >> >> Page 458 line 5: "X" (and probably "A" and "B" where they appear) >> should be in code font. This applies to the rest of the examples as well. >> >> Page 458 lines 11 and 17, page 459 lines 4 and 10, page 460 line 35, >> and page 461 line 9: "EXCLUSIVE" should be "MPI_LOCK_EXCLUSIVE". >> >> Page 458 line 23: There is extra space after "combining". >> >> Page 458 line 26: "the" should be "an". >> >> Page 458 line 38: There is extra space after "not". >> >> Page 458 line 39: "compiler and hardware specific" should be >> "compiler- and hardware-specific". >> >> Page 461 line 27: How are get-accumulate and similar operations >> incorporated into these restrictions? It would be very useful to be >> able to use fetch-and-add to get unique counter values, for example, >> although this operation will return different answers based on message >> interleavings (contradicting lines 36 and 37). >> >> How does compare-and-swap fit into the rules about accumulate_ops? Is >> compare-and-swap considered to be another reduction op for the >> purposes of the concurrent update rules, or is it a special case? >> >> Page 461 line 30: The comma should be a semicolon or colon. >> >> Page 462: Is it possible to express the different ordering models in >> terms of shared-memory consistency models (sequential, cache-coherent, >> etc.)? Those names are easier to look up than MPI-specific terms for >> accumulate_ordering values. >> >> Page 462 lines 31-32: Is this true for both memory models, or is there >> a stronger rule for the unified memory model? >> >> Page 463 lines 28 and 31: Remove the comma after "reversed". >> >> Page 463 line 30: Remove the comma after "deadlock". >> >> [may not be fixable] Page 464 lines 29-30: It looks odd to have "end >> of advice to users" after something saying that the entire section is >> advice to users. >> >> Page 464 line 32: "value" should be "values". >> >> Page 465 line 8: There is extra whitespace in this line. >> >> Page 465 lines 11-19: Section titles are in sans-serif here, while >> they are normal text in the rest of the standard. >> >> Page 465 line 43: "use" and "provide" should be "uses" and "provides", >> respectively. >> >> Page 467 line 26: There should be a space before "*/". >> >> Page 468 line 4: The semicolon should be a comma. >> >> Page 468 line 7: "naive" might need to be 'na\"\ive'. >> >> Page 469 lines 16 and 19: "A" as the variable name might need to be in >> the code font. >> >> Page 469 lines 38-39: "NSTEPS" and "M" should be in the code font, or >> else "NSTEPS" needs to be inside \mathit. >> >> Page 470 line 25: "N" might need to be in the code font or math mode. >> >> Chapter 12: >> >> Page 476 line 42: There is extra space after "request". >> >> There are a few places where "thread safe" is used as an adjective; in >> that context, it should be spelled "thread-safe". >> >> Page 487: I think MPI_INIT_THREAD should be moved to be near MPI_INIT >> in the standard, since many high-performance applications use threads >> and any threading at all (even OpenMP in non-MPI-using regions) is >> forbidden when MPI_INIT is used. >> >> [post 3.0] In the future, it might make sense for MPI_INIT to choose a >> thread mode such as MPI_THREAD_FUNNELED (or for implementations to be >> allowed to choose one) as the default when, for example, OpenMP is >> enabled by compiler settings. Many people are probably using MPI_INIT >> in OpenMP applications without knowing that MPI makes doing that >> erroneous. >> >> Page 488 lines 37-41: The text in lines 39-41 seems to contradict the >> behavior of MPI_INIT required by 37-38. >> >> Page 489 line 22: "is specified at link time." is repeated twice. >> >> It might be worthwhile to discuss MPI_MPROBE and MPI_IMPROBE and why >> they are necessary in threaded contexts in "advice to users" or >> similar non-normative text somewhere in this chapter. >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] Fwd: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 4]
by Jeff Hammond 23 Aug '12

23 Aug '12

Hi Jeremiah, I am not a chapter author but a member of the RMA working group. Thanks for your very thorough comments. I will comment on the few non-trivial ones that I am qualified to discuss. I'm sure others will comment once they've read your exhausted list and cross-checked with the standard. Best, Jeff > Why are the request-based one-sided functions named MPI_R* rather than > MPI_I* like nonblocking point-to-point and collective functions? The "I" in MPI_Isend is in reference to these functions returning "immediately", not their use of requests. MPI RMA communications operations are "nonblocking" (there was some discussion about when they could block, but I believe that is only in lock/unlock; I could be wrong) and therefore return "immediately" whether or not they involve requests, so the "immediate" name attribute is not appropriate as a distinguishing feature of the request-based operations. In any case, the MPI standard does not seek to come up with perfect names. There are plenty of functions that have unfortunate names. Users are always welcome to define their own wrappers to MPI with names they like :-) > There are no request-based versions of fetch-and-op or compare-and-swap. There was no use-case for this. I had to fight pretty hard to get request-based operations into the RMA chapter and I did so by pointing to a very reasonable use-case. If you have a use-case for request-based RMW operations, then I'm sure the Forum would be happy to consider them for MPI-Next. There's nothing stopping us from defining these operations. > Page 414 line 25: The "should" might need to be "must" to avoid issues > similar to <URL:https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=495>. I completely agree with the general point that the word "should" is useless. It is not binding, which is why legal documents use "shall" instead. I don't know if "must" has a legal meaning. The MPI standard is, of course, not a legal document, but it never hurts to use language in such a way that would stand up in court :-) > Page 433: Is it possible/likely that an rget does not complete locally until > after a flush, fence, or similar call? That might be worth mentioning if > true. I am reading this as "rget does not complete locally until a flush, fence, or similar call" since it is not clear to me what you mean by "after". I assume the meaning is "at" instead. MPI requires the user to query completion explicitly before the local buffer can be queried in a meaningful way (there is an exception for MPI_Isend and read-only access, but that's not relevant here). Polling on bytes is E.V.I.L. and not standard-compliant. Perhaps I have misunderstood your comment. > Page 487: I think MPI_INIT_THREAD should be moved to be near MPI_INIT in the > standard, since many high-performance applications use threads and any > threading at all (even OpenMP in non-MPI-using regions) is forbidden when > MPI_INIT is used. I agree with this 100%. The reason things are the way they are is presumably historical. I find it really obnoxious to have these two functions in different chapters. I'd love to see them relocated in MPI-Next. > [post 3.0] In the future, it might make sense for MPI_INIT to choose a > thread mode such as MPI_THREAD_FUNNELED (or for implementations to be > allowed to choose one) as the default when, for example, OpenMP is enabled > by compiler settings. Many people are probably using MPI_INIT in OpenMP > applications without knowing that MPI makes doing that erroneous. This would require MPI implementations to interact with the compiler, which is not something anyone I know desires. Furthermore, it is possible that an application will use MPI and OpenMP in a disjoint set of source files. How will the MPI implementation know that e.g. foo() invokes OpenMP? Do you want the linker to do something crazy with symbol redefinition to make this happen? I find many MPI users violated the standard when using OpenMP. I rebuke them whenever I observe this. I've not experienced anyone refusing to change their code to comply with the standard. I'll note that some implementations, which I will not name here to protect the guilty, support threads in a very poor way such that MPI_THREAD_FUNNELED is implemented as MPI_THREAD_MULTIPLE, meaning that it is better for uses to violate the MPI standard and take it on faith the implementation won't explode when OpenMP's Pthreads are cloned than to introduce the locking overhead of MPI_THREAD_MULTIPLE when it is entirely unnecessary. -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

[Mpi3-rma] Fwd: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 4]
by William Gropp 23 Aug '12

23 Aug '12

For those of you not on the mpi-comments list, we have been receiving a very detailed set of comments from Jeremiah Willcock. He's made it to the RMA chapter (#11); this message also include chapter 12. Please share comments on these; for the obvious typos, I as chapter author will repair them as ticket-0 changes. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign Begin forwarded message: > From: Jeremiah Willcock <jewillco(a)osl.iu.edu> > Subject: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 4] > Date: August 23, 2012 4:45:03 PM CDT > To: <mpi-comments(a)mpi-forum.org> > Reply-To: Comments on the MPI Standard <mpi-comments(a)lists.mpi-forum.org> > > These are in reference to the draft at > <URL:http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf>. Thank you for > considering them. > > -- Jeremiah Willcock > > Chapter 11: > > Why are the request-based one-sided functions named MPI_R* rather than MPI_I* like nonblocking point-to-point and collective functions? > > There are no request-based versions of fetch-and-op or compare-and-swap. > > Page 403 line 31: Add a comma after the second capital "B". > > Page 403 line 34: The semicolon here can be changed to a comma, and probably removed entirely. > > Page 404 line 15: "distributed memory" should be hyphenated. > > Page 404 line 22: The first comma should be a colon. > > Page 404 line 23: There should be a comma after "MPI_WIN_ALLOCATE_SHARED". > > Page 404 line 25: There is extra space around "to specify". > > Page 404 line 30: Should MPI be in sans-serif font? > > Page 405 line 24: Remove "and C++". > > Page 405 line 32: "address sized" should be hyphenated. > > Page 405 lines 42-43; page 408, lines 26-27; page 409, line 47: Which of these info keys must be set consistently between different processes? > > Page 406 lines 4-9: Can accumulate_ops be validly and portably set to anything other than the two values listed there? > > Page 406 line 17: There should be a comma after "units". > > Page 406 lines 42-43: "implementation specific" should be hyphenated. > > Page 409 line 44: The function name on the next line looks like it might fit on this one. > > Page 411 lines 4-5: Window flavors have not yet been introduced. In particular, the allocation functions should probably say which flavor of window they each produce. > > Page 411 lines 7-8: Some of these argument names might need to be in sans-serif. > > Page 411 lines 30-: "RMA" was written in sans-serif earlier in the chapter. > > Page 412 line 34: "MPI" should be in sans-serif. > > Page 413 line 21: "win" should be in sans-serif. > > Page 413 lines 21-22: Can the same memory be attached to different windows, just not the same window? > > Page 414 line 25: The "should" might need to be "must" to avoid issues similar to <URL:https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=495>. > > Page 415 line 12: "called" should be "call". > > Page 416 line 6: There should be commas after "disp_unit" and "create_kind". > > Page 416 line 20: There should be a comma after "returned". What if the user modifies the pointees of the pointers that are the values of these attributes in C? > > Page 416 line 28: Why return the group rather than the communicator itself? The group returned is listed as a "duplicate" -- does that mean the user is responsible for freeing it? > > Page 417 line 2: "MPI" should be in sans-serif. > > Page 417 line 12: "this" should be "the". > > Page 418 line 17: There should be a comma after "MPI_RGET_ACCUMULATE". > > Page 418 line 27: Make sure to note that "locally completed" does not mean the same thing as "completed" (I think). Will those be defined in detail later? > > Page 418 line 30: There should be a comma after "get call". > > Page 418 line 35: "; namely," can be changed to just a colon. > > Page 418 line 36: Which calls count as "accumulate calls"? > > Page 420 line 2: There should be a comma after "origin node". > > Page 420 line 31: "shared memory" should be hyphenated. > > Page 420 line 40: "occurred" should be "occurs". > > Page 422 line 7: There should be a comma after "B". > > Page 423 lines 31 and 37, page 424 lines 18 and 24: Would it be helpful to users to show the correct hints ("assert" arguments) to use in MPI_WIN_FENCE to express each fence's semantics to the implementation? > > Page 423 line 47: The example header should be on the same page as the example text. > > Page 424 line 33: I think "contribution" should be "contributions". > > Page 425 line 40: There should be a comma after "origin_count". > > Page 426 lines 9-11: Is there a valid reason that MPI_REPLACE (and MPI_NO_OP) are not allowed for MPI_REDUCE? They are not useful, most likely, but orthogonality seems to suggest that they be allowed anyway. > > Page 426 line 18: There should be a comma after "B". > > Page 426 line 46: Remove "then". > > Page 428 line 15: There is a line break (and thus probably a space in the source code) after the left parenthesis here. > > Page 428 line 26: "and MPI_NO_OP or" should be "MPI_NO_OP, or". > > Page 429: Is there a reason that there is not a similar special-case version of MPI_ACCUMULATE? > > Page 430: What happens if an MPI implementation does not support, for example, compare-and-swap on MPI_INTEGER16 values? > > Page 430 line 21: Please put compare_addr as its own variable declaration to avoid a line break between two variables. > > Page 430 line 48: "passive-target epoch" has not been defined yet as far as I know, and this use of the term does not reference a definition. > > Page 431 line 10: There should be a comma after "MPI_WIN_FLUSH_LOCAL". > > Page 432 line 15: There should be a comma after "MPI_WIN_UNLOCK". > > Page 433: Is it possible/likely that an rget does not complete locally until after a flush, fence, or similar call? That might be worth mentioning if true. > > Page 436 lines 24-25: "RMA" here should be in sans-serif (plus italic). > > Page 436 lines 26-34: This seems to imply sequential consistency between get and put accesses on the same window, even if they are not consistent with loads and stores? Or is that issue removed by the rules about overlapping get and put accesses in the same epoch? > > Page 436 lines 35-39: Can different processes see the updates in a different order (than each other's view of them, not just from the order the updates actually occurred)? > > Page 437: "passive target" and "active target" should be hyphenated. > > Page 437 line 19: "shared memory" should be hyphenated. > > Page 438 line 7: There should be a comma after "MPI_WIN_POST". > > Page 441: Does MPI_WIN_FENCE start and/or end active-target or passive-target epochs? This is answered on page 438, but the answer should be here as well. > > Page 443 line 13: There should be a space between the comma and "win". > > Page 443 line 22: "occurred" should be "occurs". > > Page 443 line 25: Insert "has" before "called". > > Does it make sense to have a nonblocking version of MPI_WIN_START? What about MPI_WIN_FENCE or the other synchronization calls that could block (MPI_WIN_WAIT already has a nonblocking version, although it does not use an MPI_Request). > > Page 445 line 21: "call" should be "calls". > > Page 445 lines 25 and 31: The "no need to wait" part is not a complete sentence. > > Page 445 lines 24-34: "initiate" should be either "initiates" or capitalized in each of these. > > Page 446 line 2: The tuple representing the graph should probably use \langle and \rangle rather than < and >; this will probably fix the spacing around them as well. > > Page 446 lines 6 and 10: "group" in each of these lines might need to be sans-serif. > > Page 447 line 48: There is extra space before "load". > > Page 448 line 1: "call" should be "calls". > > Page 448 line 3: "lock protected" should be hyphenated. > > Page 450 lines 16-18: How does this affect whether rget, rput, ... accesses have "locally completed"? Is this sentence true about those kinds of accesses until MPI_Wait is called on them? Is MPI_Wait on such a request guaranteed not to block after MPI_WIN_FLUSH_LOCAL returns? > > Page 450 line 46: "copy" should be "copies"? > > Page 451 line 15: "implementation" should be "implementation's". > > Page 451 line 17: "assertion specific" should be hyphenated. > > Page 451 line 25: There should be a comma after "MPI_MODE_NOPRECEDE". > > Page 452 lines 1 and 9: There is extra space before "stores" on each of these lines. > > Page 452 line 22: There should be a comma after "acquire". > > Page 452 line 32: "argument" should be "arguments". > > Page 452 line 43: "comm" should be in sans-serif. > > Page 453 lines 33-36: Is this text defining "complete", or just repeating a definition stated officially elsewhere? If it is the definition, the wording doesn't make that obvious. > > Page 454 lines 14 and 21: "becomes visible" means "becomes visible eventually" (in an implementation-defined amount of time); that may be worth stating explicitly here. > > Page 454 line 18: There is a space missing before "MPI_WIN_LOCK". > > Page 454 line 29: Insert "a" or "the" before "private". Which process does "the process memory" refer to? > > Page 454 lines 35-36: What is the motivation for putting "even" before "flush"? > > Page 454 line 47: This needs to be qualified with "within the same access epoch" or similar, like the next sentence is. > > Page 455 line 4: "MPI" should be sans-serif. > > Page 455 lines 26 and 29: Does "update" mean remote update here? > > Page 456 line 1: "will" should be "would". > > Page 456 line 18: "a remote process" should be plural. > > Page 456 line 23: "magnitude" should be "magnitudes". > > Page 456 line 38: There is extra space before "updates". > > Page 456 line 41: Add "elsewhere" before "in". > > Page 456 line 45: Remove "in the case". > > Page 457 line 14: There is extra space before "stores". > > Page 457 line 20: Should "being posted" be "posted" instead? The comma after "posted" can be removed. > > Page 457 line 47: "implementation dependent" should be hyphenated. > > Page 458 line 5: "X" (and probably "A" and "B" where they appear) should be in code font. This applies to the rest of the examples as well. > > Page 458 lines 11 and 17, page 459 lines 4 and 10, page 460 line 35, and page 461 line 9: "EXCLUSIVE" should be "MPI_LOCK_EXCLUSIVE". > > Page 458 line 23: There is extra space after "combining". > > Page 458 line 26: "the" should be "an". > > Page 458 line 38: There is extra space after "not". > > Page 458 line 39: "compiler and hardware specific" should be "compiler- and hardware-specific". > > Page 461 line 27: How are get-accumulate and similar operations incorporated into these restrictions? It would be very useful to be able to use fetch-and-add to get unique counter values, for example, although this operation will return different answers based on message interleavings (contradicting lines 36 and 37). > > How does compare-and-swap fit into the rules about accumulate_ops? Is compare-and-swap considered to be another reduction op for the purposes of the concurrent update rules, or is it a special case? > > Page 461 line 30: The comma should be a semicolon or colon. > > Page 462: Is it possible to express the different ordering models in terms of shared-memory consistency models (sequential, cache-coherent, etc.)? Those names are easier to look up than MPI-specific terms for accumulate_ordering values. > > Page 462 lines 31-32: Is this true for both memory models, or is there a stronger rule for the unified memory model? > > Page 463 lines 28 and 31: Remove the comma after "reversed". > > Page 463 line 30: Remove the comma after "deadlock". > > [may not be fixable] Page 464 lines 29-30: It looks odd to have "end of advice to users" after something saying that the entire section is advice to users. > > Page 464 line 32: "value" should be "values". > > Page 465 line 8: There is extra whitespace in this line. > > Page 465 lines 11-19: Section titles are in sans-serif here, while they are normal text in the rest of the standard. > > Page 465 line 43: "use" and "provide" should be "uses" and "provides", respectively. > > Page 467 line 26: There should be a space before "*/". > > Page 468 line 4: The semicolon should be a comma. > > Page 468 line 7: "naive" might need to be 'na\"\ive'. > > Page 469 lines 16 and 19: "A" as the variable name might need to be in the code font. > > Page 469 lines 38-39: "NSTEPS" and "M" should be in the code font, or else "NSTEPS" needs to be inside \mathit. > > Page 470 line 25: "N" might need to be in the code font or math mode. > > Chapter 12: > > Page 476 line 42: There is extra space after "request". > > There are a few places where "thread safe" is used as an adjective; in that context, it should be spelled "thread-safe". > > Page 487: I think MPI_INIT_THREAD should be moved to be near MPI_INIT in the standard, since many high-performance applications use threads and any threading at all (even OpenMP in non-MPI-using regions) is forbidden when MPI_INIT is used. > > [post 3.0] In the future, it might make sense for MPI_INIT to choose a thread mode such as MPI_THREAD_FUNNELED (or for implementations to be allowed to choose one) as the default when, for example, OpenMP is enabled by compiler settings. Many people are probably using MPI_INIT in OpenMP applications without knowing that MPI makes doing that erroneous. > > Page 488 lines 37-41: The text in lines 39-41 seems to contradict the behavior of MPI_INIT required by 37-38. > > Page 489 line 22: "is specified at link time." is repeated twice. > > It might be worthwhile to discuss MPI_MPROBE and MPI_IMPROBE and why they are necessary in threaded contexts in "advice to users" or similar non-normative text somewhere in this chapter. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

[Mpi3-rma] GCC CAF
by Jeff Hammond 08 Aug '12

08 Aug '12

It's obviously a bit too late for MPI-3, but it might be a useful exercise to make sure that MPI-3.0 RMA is sufficient for the GCC CAF runtime (http://gcc.gnu.org/wiki/CoarrayLib) It seems that it is though since they seem to support or attempt to support ARMCI, which we know is compatible with MPI-2.2 RMA. I know that GCC PGAS implementers are interested in MPI-3, if for no other reason than neither GASNet nor ARMCI is an RPM in any Linux distro of which I am aware. Best, Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi3-rma] MPIX_ERR_RMA_WRONG_FLAVOR
by Jim Dinan 07 Aug '12

07 Aug '12

Ok, reposted to mpi-comments. On 8/7/12 5:13 PM, Gropp, William D wrote: > This should be sent as a comment on the MPI draft. > Bill > > /Connected by DROID on Verizon Wireless/ > > > -----Original message----- > > *From: *Jim Dinan <dinan(a)mcs.anl.gov>* > To: *"MPI 3.0 Remote Memory Access working group" > <mpi3-rma(a)lists.mpi-forum.org>* > Sent: *Tue, Aug 7, 2012 21:36:22 GMT+00:00* > Subject: *[Mpi3-rma] MPIX_ERR_RMA_WRONG_FLAVOR > > Hi All, > > If we can still rename it, the error class name > MPIX_ERR_RMA_WRONG_FLAVOR should not contain "WRONG", it should just be > MPIX_ERR_RMA_FLAVOR. > > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] MPIX_ERR_RMA_WRONG_FLAVOR
by Gropp, William D 07 Aug '12

07 Aug '12

This should be sent as a comment on the MPI draft. Bill Connected by DROID on Verizon Wireless -----Original message----- From: Jim Dinan <dinan(a)mcs.anl.gov> To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma(a)lists.mpi-forum.org> Sent: Tue, Aug 7, 2012 21:36:22 GMT+00:00 Subject: [Mpi3-rma] MPIX_ERR_RMA_WRONG_FLAVOR Hi All, If we can still rename it, the error class name MPIX_ERR_RMA_WRONG_FLAVOR should not contain "WRONG", it should just be MPIX_ERR_RMA_FLAVOR. ~Jim. _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

[Mpi3-rma] MPIX_ERR_RMA_WRONG_FLAVOR
by Jim Dinan 07 Aug '12

07 Aug '12

Hi All, If we can still rename it, the error class name MPIX_ERR_RMA_WRONG_FLAVOR should not contain "WRONG", it should just be MPIX_ERR_RMA_FLAVOR. ~Jim.

1 0

Re: [Mpi3-rma] MPI-3.1 RMA planning
by James Dinan 03 Aug '12

03 Aug '12

I second this discussion. I would like to see an option for users to specify the type of data in the window rather than a disp_unit in bytes. I also think we should consider adding MPI_Win_shared_get_attr() and deprecating MPI_Win_shared_query(). ~Jim. ----- Original Message ----- From: "Pavan Balaji" <balaji(a)mcs.anl.gov> To: mpi3-rma(a)lists.mpi-forum.org Sent: Thursday, July 26, 2012 12:27:39 PM Subject: Re: [Mpi3-rma] MPI-3.1 RMA planning >> 2. The disp_unit is a weird semantic which is really meant to >> demonstrate what datatype I will be using. We are jumping through hoops >> to get the same_size and same_disp_unit measures which make little sense >> on heterogeneous systems. The correct way to do this would have been to >> not take a disp_unit parameter at all, and instead take a MPI_Datatype >> parameter. In this case, two different processes can give MPI_INT but >> have different type sizes. That adds better safety checks in MPI. > Maybe, but for some reasons, RMA windows are completely specified with > bytes. I am not sure what the reason for this was. > >> Unfortunately, all our window creation routines are screwed up in this >> manner. We should consider adding MPI_Win_create_type, >> MPI_Win_allocate_type, MPI_Win_allocate_shared_type in MPI-3.1 and >> deprecating the older routines. It would have been much better to do >> this in 3.0, but it's not a small change. > Ugs, this makes me shiver. I agree in principle, but it's ugly. This is just a starting point for discussion. I was just trying to illustrate the problem and give a starting recommendation for discussion. The underlying issue is that using bytes directly is a bad model in MPI, whether it is for send/recv or RMA.

1 0