- mpi-comments - mailman3.cels.anl.gov

Re: [Mpi-comments] RMA llist bug
by William Gropp 27 Aug '12

27 Aug '12

I'll fix this. 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 On Aug 27, 2012, at 5:34 PM, Jim Dinan wrote: > There is a bug on pg. 485, line 38: > > my_elems = realloc(my_elems, my_elems_size); > > Should be: > > my_elems = realloc(my_elems, my_elems_size*sizeof(void*)); > > ~Jim. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

RMA llist bug
by Jim Dinan 27 Aug '12

27 Aug '12

There is a bug on pg. 485, line 38: my_elems = realloc(my_elems, my_elems_size); Should be: my_elems = realloc(my_elems, my_elems_size*sizeof(void*)); ~Jim.

1 0

Comments on MPI 3.0 draft 2 [part 5]
by Jeremiah Willcock 26 Aug '12

26 Aug '12

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 13: Page 492 line 47: "8th" should be "eighth". Page 492 line 48: Although "formal parameter" is the correct term normally, MPI typically uses "argument" to mean that. Page 494 lines 11-21: Some of the example text in here might be worth putting in code font. Page 494 line 31: Is MPI_MODE_RDWR intended to be equal to MPI_MODE_RDONLY | MPI_MODE_WRONLY? If so, that will require changes in some of the nearby text. Page 495 lines 11-12: Are there any guarantees about the behavior of MPI_MODE_DELETE_ON_CLOSE if the program exits (normally or abnormally) without explicitly closing the file? Page 499 lines 44-45: Wouldn't using log on the bit to test and then mod and integer division on the amode be simpler than the loop? Floating-point errors might cause trouble there, however, or if one of the masks was not a single bit. Page 500 line 36: "Section" should be "Chapter". Page 501 line 20: There is an unnecessary line break at the end of the line. Page 501 line 47: "pair" should be "pairs". Page 502 line 3: The "and" might need to be changed to "or". Page 502 line 12: "Section" should be "Chapter". Page 502 line 34: Is there a reason that "CYCLIC" is all-uppercase? Page 503 lines 22-23: Is this hint intended to say how many devices to use, not how many are in the system? Page 505 lines 15, 25-28, and 32: "etype" and "filetype" should be in text font when they are not referring to specific argument names. Page 505 line 30: There should be a comma after "etype". Page 506 lines 30-33: Is there an easy way to tell that a datatype is derived? Is the datatype returned, if derived, guaranteed to be new (and not, for example, one passed into MPI_FILE_SET_VIEW by the user)? Page 506 lines 40-42: There is extra space after "vs." here (probably needs to be 'vs.\ ' in LaTeX). I don't remember whether vs is italicized elsewhere in the standard. Page 506 line 44: The POSIX function names might need to be in code font. Page 507 line 25: The em-dash should have spaces around it to match the rest of the standard. This issue may occur elsewhere in the chapter as well. Page 508 line 3: "in to" should be "into". Page 508 lines 9-11: Does that mean a buffer being written to a file can't be concurrently sent? It seems like that restriction may be too strong, especially when you can use a datatype to write the same data to a file more than once in a single operation. Page 509 lines 8-12: The section titles should be in the normal text font, the commas and final period should be inside the quotes, and there needs to be a comma after "Temporary Data Movements". Page 509 line 18: The fields in MPI_Status are referred to in sans-serif on page 30 where they are introduced. Page 520 lines 30-31: Do all processes need to use equivalent views of the file to use the shared file pointer? If not, what is the file pointer relative to (i.e., if I read using it in a process with one view, then read using it in a process with a different view, what happens)? Pages 524-525: Are MPI_FILE_SEEK_SHARED and/or MPI_FILE_GET_POSITION_SHARED collective? Page 534 line 24: "of the MPI-1 document" should be removed, and "page" should be "pages". Page 536 line 26: There should be a comma after "8". Page 536 line 30: This list should also include the C++ bool type now that there is an MPI datatype for it. Page 536 line 31: There should be a comma after "double _Complex". This list should include the C++ complex types. In what order do the real and imaginary components appear in the file? Page 536 lines 34-35: Unicode has several encoding formats; which one are you intending (UTF-7, UTF-8, UTF-16, UCS-16, UCS-32, or something else)? Page 537 line 5: "size" should be "sizes". Page 537 line 10: "less" should be "least". Page 537 lines 9-12: Some of this information (what happens on overflows from down-converting number formats, for example) is normative and should be in the main text. Also, taking the least-significant bytes of a larger number does not always preserve the sign bit in case of overflows (converting the MPI_INT 32768 to an MPI_INTEGER2 leads to -32768, for example). Is making sure to preserve the sign bit always the intended behavior? Page 538 line 9: Defining wchar as two bytes prevents it from representing all valid Unicode code points (some of them are above 2^16). If such code points are forbidden (even on platforms where wchar_t is 32 bits), be sure to say that explicitly. Page 538 line 40: Why is MPI_LOGICAL defined as 4 bytes instead of 1? Does the MPI standard say anywhere that a byte is assumed to be 8 bits? Page 540 line 17: There is extra whitespace at the end of the line. Page 541 lines 29 and 44: What does "equivalent" mean? That they have the same typemap and displacements, or that they are exactly the handles that the user passed in (allowing caching)? Page 541 lines 47-48: Does that mean that point-to-point operations are OK? Non-collective file I/O? Page 542 line 14: The first quotation mark is backwards. Page 542 lines 17-25: The first item in this list appears to be a superset of the third one, and it seems like all of them might be required to be satisfied when applicable (not just "at least one"). Page 542 lines 47-: "FH", "fh", and "FOO" in math mode might need to be in \mathit (I can't tell for sure). Page 543 lines 4-5: How do you get multiple file handles out of the same collective open of a file? Accesses from different processes only? Or can file descriptors be sent between processes? Page 545 line 32: There need to be spaces around the em dash. Page 546 line 27: "dup" should be "duplicate", there should be spaces around the em dash. Page 547 line 10: Is MPI_Offset required to be signed? Page 547 line 16: "KIND" might need to be in another font and/or lowercase. Page 547 line 26: "info" (and maybe "hints") should be in text font. Page 550 line 31: "myfile" might need to be in code font. Page 552 line 11: The em dash needs spaces around it. Page 552 line 27: The comma should be a period. Page 552 line 34: The line has extra space at the end. Page 555 line 40: The ranges here appear to have hyphens in them, rather than the correct en dashes. Chapter 14: Page 559 line 28: The default definition of MPI_PCONTROL needs to return successfully; that is not stated explicitly. Page 560: Line 20 should be moved above line 17 in the example so that the MPI_Type_size call is not timed. Page 560 line 33: "system" should be capitalized as a proper noun. Page 560 line 47: ", however" should be "; however,". Page 561 line 47: "they're" should be "they are", and there is extra space just before the question mark. Page 562 line 2: "single threaded" should be hyphenated. Page 562 line 18: There should be a comma after "Therefore". Page 562 line 25: "ared out" is not a standard term as far as I know; maybe say something like "copied out of the base library and into the profiling one using a tool such as ar.". Why is the information on enumerations first in the documentation, before any discussion of variables or how to use them? Page 564 line 11: There should be a comma after "tuners". Page 564 line 12: There should be a comma after "detailed". Page 564 line 27, page 565 line 14, page 567 line 22, page 571 line 26, page 591 line 45: Table captions in the standard typically do not end with periods. Page 567 line 30: Remove the comma before "which". Page 568 line 18: Add a comma and space between "type" and "as". Page 568 line 20: "enumerations" should be singular. Page 568 lines 44-45: "of at least length one" should be "of length at least one". Page 569 line 10: The first comma should be before the closing quote. Page 569 line 21: "its value" should be "their values". Page 570 line 30: Can the number and/or names of enumerators change during the course of a run? Page 570 line 42: "mpiargenumtype" is a typo. Page 571 line 33: Example titles have normally been subsections (with numbers) before the bold "Example n.n" text. Page 573 line 7: There is extra space at the end of this line. Page 573 line 18: "variables" should be singular. Page 574 line 21: There should be a comma after the right parenthesis. Page 575 lines 17-18: "implementation specific" should be hyphenated when used as an adjective (this applies to other parts of the standard as well). Page 575 line 34: "reseting" should be "resetting". Page 576-577: The datatype names in here should be in sans-serif. Page 577 line 21: "MPI_T_PVAR_CLASS_AGGREGATE" should be in sans-serif. Page 577 lines 33-34: "variable specific" and "implementation defined" both need to be hyphenated. Page 577 line 40: ", otherwise" should be "; otherwise,". Page 577 line 46: "its value" should be "their values". Page 579 line 31: Remove the comma after "one". Why are control variables and performance variables separate, given that they have so much in common and relatively few differences (in operations, attributes, etc.)? It does look like performance variables need to be relative to a session, but there can be a flag for "session-specific" or similar to handle that. Does MPI_INIT need to be called before running performance experiments? Page 580 line 44: "such object handles" should be "such an object handle". Page 581 line 1: There is extra space at the end of the line. Page 583 line 45, page 584 line 4: "sampling based" should be hyphenated. Page 584 line 6: "guaranteeing" should be "requiring". Page 584 line 11: There should be a comma after "write". Page 584 line 21: The opening quotation mark is backwards. Page 584 line 26: "clean up" should be "cleanup" or hyphenated. Page 584 line 46, page 586 line 20: These lines are indented more than those around them. Page 589 line 43: "have been" should be "may have been". Page 590 line 2: There should be a comma after "MPI_T_CATEGORY_GET_PVARS". Page 590 line 3: There should be a comma after "MPI_T_PVAR_GET_INFO". Page 590 line 20: "user provided" should be hyphenated. Page 591 lines 11-12: "or has been deleted" seems to conflict with enumeration indices not being allowed to be deleted (as far as I can tell). By the way, can they be added during the run? Page 591 line 26: The function names should be in sans-serif font. Page 591 line 31: "READREST" should be "READRESET".

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 2]
by George Bosilca 23 Aug '12

23 Aug '12

Dear Jeremiah, Thank you very much for your detailed comments on the chapters I maintain. I agree with most of your suggested changes, and I have applied them. A patch with the required changes have been sent to the gatekeepers. Thanks, george. On Aug 19, 2012, at 18:06 , Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > Page 335 lines 28-29: Are these constants required to be macros (rather than const global variables), and do they need to be defined exactly as shown? Otherwise, someone could write "#define MPI_VERSION 1+2" or (in C++) "static const int MPI_VERSION = 3;". We want them to be used in #if, so they should be #define > Page 336 line 46: "value" should be "values". > > Page 337 line 8: What is "myrank"? > > Page 337 line 12: "implementation specific" should be "implementation-specific". > > Page 337 line 23: There should be a comma before "inclusive". > > Page 337 line 41: There should not be a comma before "I/O". > > Page 341 line 26: "pointer" should be "pointers". > > Page 341 line 48: This text should end with a period, and be on the same page as the code. Done. > Page 342: What is the return value of an error handler used for? Is it meaningful at all? Is it guaranteed that, if an MPI function returns at all after an error, its return value is the same (implementation-defined) error code that was passed to the handler? The prototype of error handlers is defined on page 344 at line 11, and there is no return value. > Page 342 lines 35-36: "Thus, if the user chooses not to control error handling, every error that MPI handles is treated as fatal." is not true for I/O. The text implies MPI errors. What is the I/O specific error that is treated differently? > Page 342 lines 40-41: "non trivial" should be "non-trivial". > > Page 343 line 29: "implementation" should be "implementations". > > Page 344 line 16: "stdargs" is not a standard term. I would use varargs instead. Not very standard either, but it is a minimal change improving readability. > Page 349 lines 44-45: Line 45 appears to be redundant with the last part of line 44. Repetition is the mother of all learnings syndrome ï¿½ > Page 357 line 6: "high-resolution" should be "high resolution". Also, this text might want to repeat the wording from Annex A that MPI_{Wtime,Wtick} can be macros and/or not go through the profiling interface. There is a reference to the section that describe them as macros. > Page 357 line 18: The discussion of MPI_WTIME_IS_GLOBAL should refer to the section where it is defined. OK. > Page 357 lines 34-: MPI_INIT_THREAD is not mentioned here; this seems like the logical place to describe it. We can't just reference it, we will have to describe the function and the prototype. It is a larger change, more than I would accept at this stage. > Page 359 line 38: There is extra space in the middle of the line. Tis seems to be an issue with one of our environments leaving trash behind. We will investigate more. > Page 359 line 45: There should be a comma after "MPI_REQUEST_FREE". > > Page 359 line 48: "operations" should be "operation". > > Page 360 lines 1-2: Are there any requirements that particular objects be freed before MPI_FINALIZE? Not imposed by the standard itself. > Page 361 line 31: Who/what does "they" refer to? > > Page 362: Both functions on this page have extra whitespace in their abstract signatures. > > Page 362 line 41: There should be a comma after "accepted". > > Page 363 lines 1 and 7: "error code" should be in sans-serif. OK. Thanks, george.

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2
by George Bosilca 23 Aug '12

23 Aug '12

On Aug 23, 2012, at 20:56 , Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > On Thu, 23 Aug 2012, George Bosilca wrote: > >> >> On Aug 18, 2012, at 20:13 , Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: >> >>> On page 84 line 42, "sizeof" should be inside \mathit. >> >> ? > > "sizeof" appears to be in math mode, but since it's a multi-letter variable name, it needs to be wrapped in \mathit so that LaTeX doesn't think it's a multiplication. "buf" on line 16 of that page has the same issue, while the version on line 14 doesn't. One is inside and the other outside a math environment. Fixed. >>> On page 84 line 45, where does "i" come from? Is the extent rounded to a multiple of k_i, or is the upper bound rounded (these differ when lb is not aligned)? If extent is rounded, the +eps term should be moved to the computation of extent, not ub, unless that definition of ub is used somewhere else. >> >> Which i? The type_i or k_i? > > Both -- nothing ever says what "i" means. Right. We used j above so it make sense to keep referring to them as _j and not _i. >> The upper bound is increased in such a way that the extent is a multiple of the biggest k_i (to solve all alignment issues in the case multiple instances of the same datatype are considered). > > That's for i = 0 ... n-1, right? That is the part that is never explained in the text. It is expressed on the definition of the Typemap few lines above. >>> On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing for Fortran; I believe many other places in MPI use one-based array indices when called from Fortran, even if they use zero-based indices from C. >> >> I can't find any text that correspond to this remark. > > See page 96 lines 7-9 -- why is the function defined that way (requiring the n-1 modification to calls) for Fortran? Answered by Rajeev. >>> Also, is there a version of MPI_TYPE_CREATE_SUBARRAY that allows strided indexing in the dimensions (MPI_TYPE_CREATE_DARRAY looks more limited)? >> >> One can use a carefully hand-crafted datatype to achieve this. > > That is a suggestion to put on the list for the future. > >>> On page 115 line 44, it seems odd that adding MPI_BOTTOM to a valid address gives a valid address, since that allows me to create a valid address MPI_BOTTOM * n + v where n is nonnegative and v is a valid address. >> >> Too late to change now. We realized this few weeks ago, and we amended the example 4.18. > > This seems like it would be a serious problem for implementations that have MPI_BOTTOM != 0; why is it too late to fix? After reconsideration removing the last bullet in the list should be enough. george. > > -- Jeremiah Willcock > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2
by Rajeev Thakur 23 Aug '12

23 Aug '12

>>> On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing for Fortran; I believe many other places in MPI use one-based array indices when called from Fortran, even if they use zero-based indices from C. >> >> I can't find any text that correspond to this remark. > > See page 96 lines 7-9 -- why is the function defined that way (requiring the n-1 modification to calls) for Fortran? It is so that the Fortran binding can simply pass the array_of_starts to the C interface without having to allocate an array and copy over everything while subtracting by 1. For the user, the array_of_starts is often filled as a calculation. He can easily subtract 1 in the calculation. It has been like that since MPI-2 (1997). Rajeev

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2
by Jeremiah Willcock 23 Aug '12

23 Aug '12

On Thu, 23 Aug 2012, George Bosilca wrote: > > On Aug 18, 2012, at 20:13 , Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > >> On page 84 line 42, "sizeof" should be inside \mathit. > > ? "sizeof" appears to be in math mode, but since it's a multi-letter variable name, it needs to be wrapped in \mathit so that LaTeX doesn't think it's a multiplication. "buf" on line 16 of that page has the same issue, while the version on line 14 doesn't. >> On page 84 line 45, where does "i" come from? Is the extent rounded to >> a multiple of k_i, or is the upper bound rounded (these differ when lb >> is not aligned)? If extent is rounded, the +eps term should be moved >> to the computation of extent, not ub, unless that definition of ub is >> used somewhere else. > > Which i? The type_i or k_i? Both -- nothing ever says what "i" means. > The upper bound is increased in such a way that the extent is a multiple > of the biggest k_i (to solve all alignment issues in the case multiple > instances of the same datatype are considered). That's for i = 0 ... n-1, right? That is the part that is never explained in the text. >> On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing >> for Fortran; I believe many other places in MPI use one-based array >> indices when called from Fortran, even if they use zero-based indices >> from C. > > I can't find any text that correspond to this remark. See page 96 lines 7-9 -- why is the function defined that way (requiring the n-1 modification to calls) for Fortran? >> Also, is there a version of MPI_TYPE_CREATE_SUBARRAY that allows >> strided indexing in the dimensions (MPI_TYPE_CREATE_DARRAY looks more >> limited)? > > One can use a carefully hand-crafted datatype to achieve this. That is a suggestion to put on the list for the future. >> On page 115 line 44, it seems odd that adding MPI_BOTTOM to a valid >> address gives a valid address, since that allows me to create a valid >> address MPI_BOTTOM * n + v where n is nonnegative and v is a valid >> address. > > Too late to change now. We realized this few weeks ago, and we amended > the example 4.18. This seems like it would be a serious problem for implementations that have MPI_BOTTOM != 0; why is it too late to fix? -- Jeremiah Willcock

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2
by George Bosilca 23 Aug '12

23 Aug '12

On Aug 18, 2012, at 20:13 , Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > Chapter 4: > > On page 83 line 23, "communication" should be "communications". > > On page 83 line 34, "shape and size" should be "shapes and sizes". Done. > On page 84 line 42, "sizeof" should be inside \mathit. ? > On page 84 line 45, where does "i" come from? Is the extent rounded to a multiple of k_i, or is the upper bound rounded (these differ when lb is not aligned)? If extent is rounded, the +eps term should be moved to the computation of extent, not ub, unless that definition of ub is used somewhere else. Which i? The type_i or k_i? The upper bound is increased in such a way that the extent is a multiple of the biggest k_i (to solve all alignment issues in the case multiple instances of the same datatype are considered). > On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing for Fortran; I believe many other places in MPI use one-based array indices when called from Fortran, even if they use zero-based indices from C. I can't find any text that correspond to this remark. > Also, is there a version of MPI_TYPE_CREATE_SUBARRAY that allows strided indexing in the dimensions (MPI_TYPE_CREATE_DARRAY looks more limited)? One can use a carefully hand-crafted datatype to achieve this. > On page 103 line 18, MPI_ADDRESS has now been removed, not just deprecated. Indeed. > Is offset of a valid way to get displacements within C structs to use with MPI (rather than creating an object of that type and calling MPI_GET_ADDRESS on it and its individual fields)? Absolutely. > Wouldn't MPI_TYPE_SIZE and a way to "flatten" an MPI datatype into a datatype with the same primitive elements but sequential in memory (or using MPI_PACKED) be better than MPI_TYPE_TRUE_EXTENT for the example on page 108 line 29? There are multiple ways to achieve the goal depicted in the example. MPI_Type_get_true_extent is a valid one, even if not the most optimal in terms of memory. > On page 110 line 24, there should be a comma after "e.g.". > > On page 111 line 42, there is some odd space at the end of the line. Weird, I can't figure out how to get rid of this one. I'll investigate more. > On page 112 line 7, there shouldn't be a space after "datatype". > > On page 112 lines 11-14, should there be an MPI_TYPE_FREE added as well? Pedantic(!). > On page 115 line 44, it seems odd that adding MPI_BOTTOM to a valid address gives a valid address, since that allows me to create a valid address MPI_BOTTOM * n + v where n is nonnegative and v is a valid address. Too late to change now. We realized this few weeks ago, and we amended the example 4.18. > On page 128 line 32, example 4.18 uses "class" as a field name, which makes it impossible to compile with a C++ compiler. Fixed. Thanks, george.

1 0

Comments on MPI 3.0 draft 2 [part 4]
by Jeremiah Willcock 23 Aug '12

23 Aug '12

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.

1 0

Comments on MPI 3.0 draft 2 [part 3]
by Jeremiah Willcock 20 Aug '12

20 Aug '12

These are in reference to the draft at <URL:http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf>. Thank you for considering them. Chapter 9: Page 367 line 21: There is an extra space before "value" that is not in other occurrences of that pair name. Page 367 line 29: Why is there a standard-defined upper limit on key length, rather than just saying it's up to implementations? Page 367 line 30: There is no lower bound given on MPI_MAX_INFO_VAL, allowing an implementation to have an absurdly low limit such as one character. Page 368 line 2: Are all strings consisting only of an (optional) sign and decimal digits considered to be decimal (and not octal if they begin with a leading zero)? This issue has come up in practice. Page 368 line 3: There is an extra space before "integer". Page 368 line 6: What is a "valid element"? Is that just a value of the correct type for that particular info key? Is it possible to have lists of lists? Is there a way to escape a comma in a list element? Page 369 line 16: What if the key is too long? Page 370 line 29: Why does this particular case of the key being too long not return a defined error class, while the other functions do? Chapter 10: The chapter uses "intercommunicator" as one word, which is inconsistent with the chapter on communicators. Page 373 line 19: "allow" should be "allows". Page 373 line 24: "later" should be "latter". Page 373 line 32: There is extra space before and after "MPI". Page 374 line 31: There is extra space before "group". Page 376 line 1: There is extra space after "MPI_UNIVERSE_SIZE". Page 376 lines 11-12: "(group,rank)" was written without spaces before this, but with spaces here. Page 376 line 21: "starting first" should be "first starting". Page 377 line 1 and page 382: Is there a reason that argv is not "const char* const argv[]" or similar? Compatibility? Page 378 lines 13-18: This is written very informally. Page 378 lines 22-23: Is there a way to pass an empty argument in Fortran without terminating the argument list? Page 379 line 36: "soft" should be in italics (the one on line 37 should not be). Page 380 line 3: The 9 here refers to a chapter, not a section. Page 380 line 16: Must the root argument be consistent across the entire communicator? Page 380 line 24: Must the same error code be used for all the failed processes? If not, the "error code" part needs to be plural. Page 380 lines 30-32: This refers to the C++ binding which have been removed. Page 381 lines 13-14: Is calling MPI_COMM_FREE on the parent intercommunicator an error? If not, why not? Page 382 lines 35-36: These argument declarations should be separate so the list of variables is not split onto two lines. Page 383 line 25: Why can't MPI_ARGV_NULL be used for individual commands? Page 384 lines 7-8: The command name and arguments should be in the code font. Page 384 line 17: This text is very informal. Page 384 lines 37-: Lines 2+ of each of these paragraphs does not line up with the text on the first line. Page 384 line 45: "path" should be in sans-serif. Page 385 line 15: Is c allowed to be zero? Is b allowed to be equal to a? Page 385 lines 20 and 23: Add "a" (on 20) and "an" (on 23) after "allows". Page 385 line 27: There is extra space before "Using". For spawned processes, what happens if one or more of the child processes calls MPI_Finalize? MPI_Abort? What about one or more of the parents? Which processes can continue in those cases, and what happens to the various communicators? Page 400 mentions it for connected processes, but are the rules for children different? Page 387 line 27: "client server" should be "client/server". Page 387 line 44: There should be a comma after "simple". Page 387 line 45 and page 389 lines 19 and 29: "internet" may or may not need to be capitalized depending on which meaning is intended. Page 387 line 47: The comma should be a semicolon. Page 389 line 19 and others: Some or all of "(host:port)" might need to be in sans-serif or code font. Page 390 line 33 and page 391 line 26: Must root be the same on all processes in the communicator? Page 391 line 37: "high quality" should be "high-quality". Page 391 line 40: There should be a comma after "MPI_COMM_ACCEPT". Page 392 line 2: Some parts of this line should be in sans-serif or code font. Page 392 line 42: Should the behavior be implementation-dependent (with a defined error class if the implementation chooses to return an error) rather than completely undefined? Page 394 line 33: IP does not have port numbers; they are added by higher-level protocols such as TCP and UDP. Page 395 line 9: "stdin" should be in the code font. Page 395 lines 22-34: Do some of these calls need to execute on only a single rank if the program is parallel? Page 396 line 17: Doesn't the client need to be disconnected explicitly in this case as well? Page 399 lines 35-36 seem to say that. Page 399 lines 11-12: Having only a single "appnum" info argument for MPI_COMM_SPAWN_MULTIPLE breaks the usual mechanism in which each command spawned gets a different MPI_APPNUM. Is there a way to specify a list of appnums instead of a single one for MPI_COMM_SPAWN_MULTIPLE? Page 399 line 46: There should be a comma before "may". Page 400: What does MPI_COMM_DISCONNECT do to/on spawned processes? Page 400 line 36: There should be a comma after "MPI_WIN_FREE". Page 400 line 38: "Notes" should be "Note". Page 402 line 12: Does "concurrently" mean "concurrently on the same socket"? -- Jeremiah Willcock

1 0