May 2013 - mpiwg-tools - mailman3.cels.anl.gov

Re: [Mpi3-tools] latest draft of mqs
by John DelSignore 24 May '13

24 May '13

Hi Anh, Attached is my latest round of edits/comments. Overall, I think the document looks better than ever, though if I look at it with a critical eye, there is still much room for improvement. My basic complaints: * Lack of examples. * The language is a bit loose in many places and hedges a lot, using words like ï¿½shouldï¿½ and phrases like ï¿½the debugger willï¿½. * The descriptions of some functions are very sparse, and could stand further elaboration. Cheers, John D. Anh Vo wrote: > I've uploaded the PDF to the ticket and mailed the forum. IMO, the proposal is in very good shape after the last round of feedbacks. Changes from this point will mostly be spelling/grammar/clarification of a few things. Those changes will be applied following the Forum's procedural rules. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo > Sent: Friday, May 24, 2013 10:07 AM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Yes - I realized you missed the definition of "Image file" and I did include its definition in the chap3.pdf file that I sent > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore > Sent: Friday, May 24, 2013 10:03 AM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Thanks. I accidentally missed the definition of "Image File" in my first email, which I think should be: > > 3.6 Image File > An image file is an executable or shared library file, which may contain symbol definitions needed by the MQD interface. > > And all of the later 3.x sections have to get renumbered, but I assume LaTex will do that for you automatically. > > Cheers, John D. > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo > Sent: Friday, May 24, 2013 12:26 PM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > I incorporated your edits into the current docs. Thank you! Attached is the chapter 3 with the new layout (each definition has its own section). Note that in the PDF I sent yesterday, each of the callback function in the mqs_basic_callbacks, mqs_image_callbacks, and mqs_process_callbacks also got it own subsection (based on Martin's feedbacks) > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore > Sent: Friday, May 24, 2013 8:58 AM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi Anh, > > I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). > > I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. > > More later... > > Cheers, John D > > -----------------------cut-here--------------------------- > > Chapter 3 > > Definitions > > 3.1 Shared Library > A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. > > 3.2 Shared Object File > The term used on UNIX and UNIX-based systems to describe a shared library. > > 3.3 Dynamic-Link Library > The term used on Windows and OS/2 systems to describe a shared library. > > 3.4 Dynamically Loaded Library > A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. > > 3.5 DLL > An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. > > 3.6 MPI Process > An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. > > 3.7 Address Space > An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. > > 3.8 "mqs_image" > An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. > > 3.9 "Starter" Process Definition > The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. > > 3.10 Host and Target Node Definitions > For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. > > -----------------------cut-here--------------------------- > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo > Sent: Thursday, May 23, 2013 4:49 PM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. > > The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore > Sent: Thursday, May 23, 2013 12:52 PM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] latest draft of mqs > > Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. > > One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. > > Cheers, John D. > > > Anh Vo wrote: >> Hi all, >> >> I have updated the MQS draft incorporating most of John's feedbacks. >> There are still a few items here and there and I plan to get it done >> by the end of today so we can send it out to the forum before Friday >> noon as we promised. >> >> I'm sending this now since I need feedbacks on some of the new >> definitions provided in chapter 3. Please look at Chapter 3. Note that >> due to our definition of mqs_image, the document will use >> \emph{mqs_image} in place of image (this is one part that I will go >> through and make sure I change them). \variable{mqs_image} will be >> used when referring to the type mqs_image of the interface. >> >> >> >> --Anh >> >> >> >> >> >> >> >> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >> [mailto:[email protected]] *On Behalf Of *Kathryn >> Mohror >> *Sent:* Wednesday, May 22, 2013 2:16 PM >> *To:* mpi3-tools(a)lists.mpi-forum.org >> *Subject:* Re: [Mpi3-tools] latest draft of mqs >> >> >> >> Comments inline >> >> >> >> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> [mailto:[email protected] >> <mailto:[email protected]>] *On Behalf Of *Kathryn >> Mohror >> *Sent:* Wednesday, May 22, 2013 1:44 PM >> *To:* mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> >> *Subject:* Re: [Mpi3-tools] latest draft of mqs >> >> >> >> Hi Ahn, >> >> >> >> comments inline: >> >> Page 2, Comment JD4 >> John's comments about lots of hyphenated identifiers at end of line. >> Some of it are artifacts of converting PDF -> Word, but I think this >> is a common (and widely accepted) problems of latex documents. So we >> will probably have to live with it unless there're some magic way to >> make it nicer. >> >> >> >> I searched the standard (with PDF viewer search) and didn't see any >> broken hyphenated identifiers at the ends of lines. I noted that in >> the standard type and function names are like so: MPI\_COMM\_WORLD >> while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If >> you remove the \- will it do the right thing? I am not a Latex guru >> so I don't know. >> >> [anhvo]: Yes, I think I mainly followed the practice of the latex in >> MPIR and put the \- there, it basically tells Latex it can break off >> the lines there. Not sure which one is more desirable? >> >> >> >> I don't care either way really, except I think it looks bad if words >> go past the end of the margin if LaTeX doesn't know what to do with >> the word. There's probably some magic to fix that but I don't know it. >> >> >> >> >> >> Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted >> table similar to what the MPIR document had. For example: >> >> Char MPIR_dll_name[] >> Definition is required >> Definition is contained within the address space of the MPI process >> Variable is written by the MPI process, and read by the tool >> >> I thought I did ask about this in the conf call at some point (or >> maybe it was an email, I can't remember the exact time and place) and >> we agreed that we would not be using that format because many people >> in the forum thought it was weird looking. >> >> >> >> Well, my opinion is that it should be consistent with what is in MPIR >> since it's supposed to be part of the same document. I don't remember >> the 'weird looking' comment, but I wouldn't be surprised if someone made it. >> >> [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to >> me. And I agreed with Jeff so I removed it. I might be in the minority >> but I don't necessarily agree that we should have similar format with >> the MPIR Document. They're both side documents but they're quite >> different. In MPIR there are many variables so it's quite important to >> mention where they should stay and who is writing, reading it. In MQS >> we separate callbacks by debugger and DLL so it's quite clear who >> should define what >> >> >> >> Maybe a compromise is to put this sort of information at the top of >> each section.subsection that defines a set of variables? You already >> say it in the text, but pulling it out somehow may be helpful to >> people new to the interface. It's just an idea... I'm not married to it. >> >> >> >> Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at >> the end of the typedef definition? When I first created the document, >> I also debated a bit between this. I ended up following the style of >> the MPI standard where it lists the C declaration without any ; I'm >> fine either way, but would like to hear others' opinions on this. >> >> >> >> I think the standard does use ; . At least I didn't see any -- did I >> miss what you mean? >> >> [anhvo]: The standard does not put semicolon after a C definition. >> Randomly picking: page 38, C definition of MPI_BSend: >> >> int MPI_Bsend(...) (no semicolon at the end) >> >> >> >> Oh, yes I see what you mean. Okay, given that I would vote for no ; >> >> >> >> Kathryn >> >> >> >> >> >> Thanks for your hard work Ahn! >> >> Kathryn >> >> >> >> >> I'm leaving for lunch now. More comments after I'm back. In the >> meantime, if folks can comments on what I've sent so far, that'd be >> great!! >> >> Thanks >> Anh >> >> -----Original Message----- >> From: mpi3-tools-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of Anh Vo >> Sent: Wednesday, May 22, 2013 8:10 AM >> To: mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> >> Subject: Re: [Mpi3-tools] latest draft of mqs >> >> The definitions John provide look great for me. Unless there are >> other opinions, I will use those. >> >> --Anh >> >> -----Original Message----- >> From: mpi3-tools-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of Ahn, Dong H. >> Sent: Wednesday, May 22, 2013 7:54 AM >> To: mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> >> Subject: Re: [Mpi3-tools] latest draft of mqs >> >> Hi John, >> >> This works for me and should clarify a few things in the current draft. >> >> Best, >> Dong >> >> >> >> -----Original Message----- >> From: mpi3-tools-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of John >> DelSignore >> Sent: Wednesday, May 22, 2013 9:55 AM >> To: mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> >> Subject: Re: [Mpi3-tools] latest draft of mqs >> >> I prefer to not muddy up the "standard definitions" (or maybe >> "common-sense definitions") of commonly used term, such as "image >> file", to make them conform to the MQD interface. Instead, I like to >> define the MQD typedefs in terms of the standard definitions. So, >> WRT to the document, I think we should include the following >> definitions: >> >> * An "image file" is an executable or shared library file, that may >> contain symbol definitions needed by the MQD interface. >> >> * An "MPI process" consists of an "address space" and a collection >> of execution contexts (threads or lightweight processes). >> >> * An "address space" is a region of memory that consists of executable >> code and data, and is partially composed of a collection of image >> files. The collection of image files may change at any point during >> the execution of the MPI process, and image files may be relocated >> at runtime within the address space at the point they are loaded >> into memory. >> >> Then we can say: >> >> * An "mqs_image" is an abstract concept that represents the collection >> of image files loaded into the address space of the MPI process at any >> given time, and is debugger implementation defined. In static >> execution environments, where shared libraries are not supported, an >> mqs_image can represent an executable image file. However, in dynamic >> execution environments, where shared libraries, dynamically loaded >> shared libraries, and runtime relocation of shared libraries are >> supported, an mqs_image should represent the collection of image >> files loaded into the address space of the MPI process at any given >> point in time; in this situation, mqs_image may in fact represent >> the MPI process itself. >> >> Cheers, John D. >> >> >> Anh Vo wrote: >> >> >> Thanks Kathryn for starting up the discussion. >> >> >> >> I'll start with my existing definition of mqs_image in the document, >> which definitely is not adequate. >> >> >> >> Existing definition: >> >> An image is an executable file that was loaded into memory when >> >> a process is started. For SIMD-style programs, all MPI processes >> have >> >> the same image. For MIMD-style programs, MPI processes might have >> >> different images. >> >> >> >> Dong's comments: >> >> The definition of "Image" isn't all that rigorous here. I think this >> creates some confusion somewhere down this document. Is an image >> really an executable file? Which typically means the base >> executable or does this refer to both the based executable and DSOs >> being loaded into the process address space? Though it sounds >> hair-splitting, even the SPMD remark, the statement is only true if >> the image is defined to be the base executable. >> >> >> >> John's comments: >> >> I think we should be more general with the term "image" to mean >> executable or shared library. The reason is that we do not want to >> require symbols to reside in the executable. We should allow symbols >> to reside in shared libraries. >> >> Also, I think we need to define the "address space" of a process, >> and an "image list" as a collection of image files that have been >> loaded in the address space, and possibly relocated at runtime. >> >> >> >> I think I agree with both comments. Image should not refer to a >> single executable image (a.out or a.exe), but rather the base >> executable and the shared libraries that were loaded into the >> process address space. >> >> >> >> So how about this new definition: >> >> An image represents the executable (e.g., a.out) and the collection >> of dynamically loaded libraries that were loaded into the process >> address space. >> >> >> >> --Anh >> >> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] *On Behalf Of >> *Kathryn Mohror >> *Sent:* Tuesday, May 21, 2013 6:27 PM >> *To:* mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> >> *Subject:* Re: [Mpi3-tools] latest draft of mqs >> >> >> >> Hi John, >> >> >> >> Thank you for the extensive feedback and help with the document! I'm >> sure you will get the 'nod' you referred to on page 1 :-) >> >> >> >> For the definition of mqs_image, I agree that it needs work. Dong >> Ahn also mentioned that it needed to be more rigorously defined. >> However if possible, I think it would be beneficial if we could at >> least start the conversation before next week so that we have a >> better chance of having it nailed down in advance of the next meeting. >> >> >> >> So, that said -- does anyone want to take a first stab at a >> definition to get us started? >> >> >> >> Kathryn >> >> >> >> On May 21, 2013, at 2:18 PM, John DelSignore >> <John.DelSignore(a)roguewave.com <mailto:[email protected]> >> <mailto:[email protected]>> >> wrote: >> >> >> >> Hi, >> >> Attached are my edits and comments on the MPI Message Queue >> document. Anh provided me with a Word document generated from the >> LaTex, so the formatting is funky in some places. I enabled change >> tracking in Word before making my edits, and I added many comments >> to the document in places where I think we have more work to do. >> Unfortunately, I think the changes might be somewhat extensive. >> >> The volume of edits and comments aside, I think Anh did a great job! >> The first draft of the document closely reflects the 10+ year-old >> description of the interface pretty well. Unfortunately, the >> original interface has some problem that we need to resolve, most >> critically, we have to resolve how to describe the concept of >> "mqs_image". We can talk about this during the next concall. >> >> Cheers, John D. >> >> >> Anh Vo wrote: >> >> Hi all, >> >> As mentioned on the tool WG call today, I'm re-sending the >> latest draft. >> Feedbacks are appreciated. We'll send this one out to the wider >> audience >> on Tuesday 5/21 to meet the requirement for first reading in >> June >> >> >> >> --Anh >> >> <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> <mailto:[email protected]> <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> >> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >> Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> <msgq.pdf>_______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov >> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >> Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov >> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >> Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >

1 0

Re: [Mpi3-tools] latest draft of mqs
by Anh Vo 24 May '13

24 May '13

I've uploaded the PDF to the ticket and mailed the forum. IMO, the proposal is in very good shape after the last round of feedbacks. Changes from this point will mostly be spelling/grammar/clarification of a few things. Those changes will be applied following the Forum's procedural rules. --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Friday, May 24, 2013 10:07 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Yes - I realized you missed the definition of "Image file" and I did include its definition in the chap3.pdf file that I sent -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 10:03 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks. I accidentally missed the definition of "Image File" in my first email, which I think should be: 3.6 Image File An image file is an executable or shared library file, which may contain symbol definitions needed by the MQD interface. And all of the later 3.x sections have to get renumbered, but I assume LaTex will do that for you automatically. Cheers, John D. -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Friday, May 24, 2013 12:26 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, I incorporated your edits into the current docs. Thank you! Attached is the chapter 3 with the new layout (each definition has its own section). Note that in the PDF I sent yesterday, each of the callback function in the mqs_basic_callbacks, mqs_image_callbacks, and mqs_process_callbacks also got it own subsection (based on Martin's feedbacks) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 8:58 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi Anh, I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. More later... Cheers, John D -----------------------cut-here--------------------------- Chapter 3 Definitions 3.1 Shared Library A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. 3.2 Shared Object File The term used on UNIX and UNIX-based systems to describe a shared library. 3.3 Dynamic-Link Library The term used on Windows and OS/2 systems to describe a shared library. 3.4 Dynamically Loaded Library A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. 3.5 DLL An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. 3.6 MPI Process An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. 3.7 Address Space An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. 3.8 "mqs_image" An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. 3.9 "Starter" Process Definition The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. 3.10 Host and Target Node Definitions For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. -----------------------cut-here--------------------------- -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Thursday, May 23, 2013 4:49 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, May 23, 2013 12:52 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. Cheers, John D. Anh Vo wrote: > Hi all, > > I have updated the MQS draft incorporating most of John's feedbacks. > There are still a few items here and there and I plan to get it done > by the end of today so we can send it out to the forum before Friday > noon as we promised. > > I'm sending this now since I need feedbacks on some of the new > definitions provided in chapter 3. Please look at Chapter 3. Note that > due to our definition of mqs_image, the document will use > \emph{mqs_image} in place of image (this is one part that I will go > through and make sure I change them). \variable{mqs_image} will be > used when referring to the type mqs_image of the interface. > > > > --Anh > > > > > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 2:16 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Comments inline > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 1:44 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi Ahn, > > > > comments inline: > > Page 2, Comment JD4 > John's comments about lots of hyphenated identifiers at end of line. > Some of it are artifacts of converting PDF -> Word, but I think this > is a common (and widely accepted) problems of latex documents. So we > will probably have to live with it unless there're some magic way to > make it nicer. > > > > I searched the standard (with PDF viewer search) and didn't see any > broken hyphenated identifiers at the ends of lines. I noted that in > the standard type and function names are like so: MPI\_COMM\_WORLD > while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If > you remove the \- will it do the right thing? I am not a Latex guru > so I don't know. > > [anhvo]: Yes, I think I mainly followed the practice of the latex in > MPIR and put the \- there, it basically tells Latex it can break off > the lines there. Not sure which one is more desirable? > > > > I don't care either way really, except I think it looks bad if words > go past the end of the margin if LaTeX doesn't know what to do with > the word. There's probably some magic to fix that but I don't know it. > > > > > > Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted > table similar to what the MPIR document had. For example: > > Char MPIR_dll_name[] > Definition is required > Definition is contained within the address space of the MPI process > Variable is written by the MPI process, and read by the tool > > I thought I did ask about this in the conf call at some point (or > maybe it was an email, I can't remember the exact time and place) and > we agreed that we would not be using that format because many people > in the forum thought it was weird looking. > > > > Well, my opinion is that it should be consistent with what is in MPIR > since it's supposed to be part of the same document. I don't remember > the 'weird looking' comment, but I wouldn't be surprised if someone made it. > > [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to > me. And I agreed with Jeff so I removed it. I might be in the minority > but I don't necessarily agree that we should have similar format with > the MPIR Document. They're both side documents but they're quite > different. In MPIR there are many variables so it's quite important to > mention where they should stay and who is writing, reading it. In MQS > we separate callbacks by debugger and DLL so it's quite clear who > should define what > > > > Maybe a compromise is to put this sort of information at the top of > each section.subsection that defines a set of variables? You already > say it in the text, but pulling it out somehow may be helpful to > people new to the interface. It's just an idea... I'm not married to it. > > > > Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at > the end of the typedef definition? When I first created the document, > I also debated a bit between this. I ended up following the style of > the MPI standard where it lists the C declaration without any ; I'm > fine either way, but would like to hear others' opinions on this. > > > > I think the standard does use ; . At least I didn't see any -- did I > miss what you mean? > > [anhvo]: The standard does not put semicolon after a C definition. > Randomly picking: page 38, C definition of MPI_BSend: > > int MPI_Bsend(...) (no semicolon at the end) > > > > Oh, yes I see what you mean. Okay, given that I would vote for no ; > > > > Kathryn > > > > > > Thanks for your hard work Ahn! > > Kathryn > > > > > I'm leaving for lunch now. More comments after I'm back. In the > meantime, if folks can comments on what I've sent so far, that'd be > great!! > > Thanks > Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Anh Vo > Sent: Wednesday, May 22, 2013 8:10 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > The definitions John provide look great for me. Unless there are > other opinions, I will use those. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Ahn, Dong H. > Sent: Wednesday, May 22, 2013 7:54 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > > This works for me and should clarify a few things in the current draft. > > Best, > Dong > > > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John > DelSignore > Sent: Wednesday, May 22, 2013 9:55 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > I prefer to not muddy up the "standard definitions" (or maybe > "common-sense definitions") of commonly used term, such as "image > file", to make them conform to the MQD interface. Instead, I like to > define the MQD typedefs in terms of the standard definitions. So, > WRT to the document, I think we should include the following > definitions: > > * An "image file" is an executable or shared library file, that may > contain symbol definitions needed by the MQD interface. > > * An "MPI process" consists of an "address space" and a collection > of execution contexts (threads or lightweight processes). > > * An "address space" is a region of memory that consists of executable > code and data, and is partially composed of a collection of image > files. The collection of image files may change at any point during > the execution of the MPI process, and image files may be relocated > at runtime within the address space at the point they are loaded > into memory. > > Then we can say: > > * An "mqs_image" is an abstract concept that represents the collection > of image files loaded into the address space of the MPI process at any > given time, and is debugger implementation defined. In static > execution environments, where shared libraries are not supported, an > mqs_image can represent an executable image file. However, in dynamic > execution environments, where shared libraries, dynamically loaded > shared libraries, and runtime relocation of shared libraries are > supported, an mqs_image should represent the collection of image > files loaded into the address space of the MPI process at any given > point in time; in this situation, mqs_image may in fact represent > the MPI process itself. > > Cheers, John D. > > > Anh Vo wrote: > > > Thanks Kathryn for starting up the discussion. > > > > I'll start with my existing definition of mqs_image in the document, > which definitely is not adequate. > > > > Existing definition: > > An image is an executable file that was loaded into memory when > > a process is started. For SIMD-style programs, all MPI processes > have > > the same image. For MIMD-style programs, MPI processes might have > > different images. > > > > Dong's comments: > > The definition of "Image" isn't all that rigorous here. I think this > creates some confusion somewhere down this document. Is an image > really an executable file? Which typically means the base > executable or does this refer to both the based executable and DSOs > being loaded into the process address space? Though it sounds > hair-splitting, even the SPMD remark, the statement is only true if > the image is defined to be the base executable. > > > > John's comments: > > I think we should be more general with the term "image" to mean > executable or shared library. The reason is that we do not want to > require symbols to reside in the executable. We should allow symbols > to reside in shared libraries. > > Also, I think we need to define the "address space" of a process, > and an "image list" as a collection of image files that have been > loaded in the address space, and possibly relocated at runtime. > > > > I think I agree with both comments. Image should not refer to a > single executable image (a.out or a.exe), but rather the base > executable and the shared libraries that were loaded into the > process address space. > > > > So how about this new definition: > > An image represents the executable (e.g., a.out) and the collection > of dynamically loaded libraries that were loaded into the process > address space. > > > > --Anh > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of > *Kathryn Mohror > *Sent:* Tuesday, May 21, 2013 6:27 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi John, > > > > Thank you for the extensive feedback and help with the document! I'm > sure you will get the 'nod' you referred to on page 1 :-) > > > > For the definition of mqs_image, I agree that it needs work. Dong > Ahn also mentioned that it needed to be more rigorously defined. > However if possible, I think it would be beneficial if we could at > least start the conversation before next week so that we have a > better chance of having it nailed down in advance of the next meeting. > > > > So, that said -- does anyone want to take a first stab at a > definition to get us started? > > > > Kathryn > > > > On May 21, 2013, at 2:18 PM, John DelSignore > <John.DelSignore(a)roguewave.com <mailto:[email protected]> > <mailto:[email protected]>> > wrote: > > > > Hi, > > Attached are my edits and comments on the MPI Message Queue > document. Anh provided me with a Word document generated from the > LaTex, so the formatting is funky in some places. I enabled change > tracking in Word before making my edits, and I added many comments > to the document in places where I think we have more work to do. > Unfortunately, I think the changes might be somewhat extensive. > > The volume of edits and comments aside, I think Anh did a great job! > The first draft of the document closely reflects the 10+ year-old > description of the interface pretty well. Unfortunately, the > original interface has some problem that we need to resolve, most > critically, we have to resolve how to describe the concept of > "mqs_image". We can talk about this during the next concall. > > Cheers, John D. > > > Anh Vo wrote: > > Hi all, > > As mentioned on the tool WG call today, I'm re-sending the > latest draft. > Feedbacks are appreciated. We'll send this one out to the wider > audience > on Tuesday 5/21 to meet the requirement for first reading in > June > > > > --Anh > > <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > <msgq.pdf>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] latest draft of mqs
by Anh Vo 24 May '13

24 May '13

Yes - I realized you missed the definition of "Image file" and I did include its definition in the chap3.pdf file that I sent -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 10:03 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks. I accidentally missed the definition of "Image File" in my first email, which I think should be: 3.6 Image File An image file is an executable or shared library file, which may contain symbol definitions needed by the MQD interface. And all of the later 3.x sections have to get renumbered, but I assume LaTex will do that for you automatically. Cheers, John D. -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Friday, May 24, 2013 12:26 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, I incorporated your edits into the current docs. Thank you! Attached is the chapter 3 with the new layout (each definition has its own section). Note that in the PDF I sent yesterday, each of the callback function in the mqs_basic_callbacks, mqs_image_callbacks, and mqs_process_callbacks also got it own subsection (based on Martin's feedbacks) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 8:58 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi Anh, I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. More later... Cheers, John D -----------------------cut-here--------------------------- Chapter 3 Definitions 3.1 Shared Library A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. 3.2 Shared Object File The term used on UNIX and UNIX-based systems to describe a shared library. 3.3 Dynamic-Link Library The term used on Windows and OS/2 systems to describe a shared library. 3.4 Dynamically Loaded Library A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. 3.5 DLL An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. 3.6 MPI Process An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. 3.7 Address Space An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. 3.8 "mqs_image" An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. 3.9 "Starter" Process Definition The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. 3.10 Host and Target Node Definitions For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. -----------------------cut-here--------------------------- -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Thursday, May 23, 2013 4:49 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, May 23, 2013 12:52 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. Cheers, John D. Anh Vo wrote: > Hi all, > > I have updated the MQS draft incorporating most of John's feedbacks. > There are still a few items here and there and I plan to get it done > by the end of today so we can send it out to the forum before Friday > noon as we promised. > > I'm sending this now since I need feedbacks on some of the new > definitions provided in chapter 3. Please look at Chapter 3. Note that > due to our definition of mqs_image, the document will use > \emph{mqs_image} in place of image (this is one part that I will go > through and make sure I change them). \variable{mqs_image} will be > used when referring to the type mqs_image of the interface. > > > > --Anh > > > > > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 2:16 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Comments inline > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 1:44 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi Ahn, > > > > comments inline: > > Page 2, Comment JD4 > John's comments about lots of hyphenated identifiers at end of line. > Some of it are artifacts of converting PDF -> Word, but I think this > is a common (and widely accepted) problems of latex documents. So we > will probably have to live with it unless there're some magic way to > make it nicer. > > > > I searched the standard (with PDF viewer search) and didn't see any > broken hyphenated identifiers at the ends of lines. I noted that in > the standard type and function names are like so: MPI\_COMM\_WORLD > while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If > you remove the \- will it do the right thing? I am not a Latex guru > so I don't know. > > [anhvo]: Yes, I think I mainly followed the practice of the latex in > MPIR and put the \- there, it basically tells Latex it can break off > the lines there. Not sure which one is more desirable? > > > > I don't care either way really, except I think it looks bad if words > go past the end of the margin if LaTeX doesn't know what to do with > the word. There's probably some magic to fix that but I don't know it. > > > > > > Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted > table similar to what the MPIR document had. For example: > > Char MPIR_dll_name[] > Definition is required > Definition is contained within the address space of the MPI process > Variable is written by the MPI process, and read by the tool > > I thought I did ask about this in the conf call at some point (or > maybe it was an email, I can't remember the exact time and place) and > we agreed that we would not be using that format because many people > in the forum thought it was weird looking. > > > > Well, my opinion is that it should be consistent with what is in MPIR > since it's supposed to be part of the same document. I don't remember > the 'weird looking' comment, but I wouldn't be surprised if someone made it. > > [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to > me. And I agreed with Jeff so I removed it. I might be in the minority > but I don't necessarily agree that we should have similar format with > the MPIR Document. They're both side documents but they're quite > different. In MPIR there are many variables so it's quite important to > mention where they should stay and who is writing, reading it. In MQS > we separate callbacks by debugger and DLL so it's quite clear who > should define what > > > > Maybe a compromise is to put this sort of information at the top of > each section.subsection that defines a set of variables? You already > say it in the text, but pulling it out somehow may be helpful to > people new to the interface. It's just an idea... I'm not married to it. > > > > Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at > the end of the typedef definition? When I first created the document, > I also debated a bit between this. I ended up following the style of > the MPI standard where it lists the C declaration without any ; I'm > fine either way, but would like to hear others' opinions on this. > > > > I think the standard does use ; . At least I didn't see any -- did I > miss what you mean? > > [anhvo]: The standard does not put semicolon after a C definition. > Randomly picking: page 38, C definition of MPI_BSend: > > int MPI_Bsend(...) (no semicolon at the end) > > > > Oh, yes I see what you mean. Okay, given that I would vote for no ; > > > > Kathryn > > > > > > Thanks for your hard work Ahn! > > Kathryn > > > > > I'm leaving for lunch now. More comments after I'm back. In the > meantime, if folks can comments on what I've sent so far, that'd be > great!! > > Thanks > Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Anh Vo > Sent: Wednesday, May 22, 2013 8:10 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > The definitions John provide look great for me. Unless there are > other opinions, I will use those. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Ahn, Dong H. > Sent: Wednesday, May 22, 2013 7:54 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > > This works for me and should clarify a few things in the current draft. > > Best, > Dong > > > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John > DelSignore > Sent: Wednesday, May 22, 2013 9:55 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > I prefer to not muddy up the "standard definitions" (or maybe > "common-sense definitions") of commonly used term, such as "image > file", to make them conform to the MQD interface. Instead, I like to > define the MQD typedefs in terms of the standard definitions. So, > WRT to the document, I think we should include the following > definitions: > > * An "image file" is an executable or shared library file, that may > contain symbol definitions needed by the MQD interface. > > * An "MPI process" consists of an "address space" and a collection > of execution contexts (threads or lightweight processes). > > * An "address space" is a region of memory that consists of executable > code and data, and is partially composed of a collection of image > files. The collection of image files may change at any point during > the execution of the MPI process, and image files may be relocated > at runtime within the address space at the point they are loaded > into memory. > > Then we can say: > > * An "mqs_image" is an abstract concept that represents the collection > of image files loaded into the address space of the MPI process at any > given time, and is debugger implementation defined. In static > execution environments, where shared libraries are not supported, an > mqs_image can represent an executable image file. However, in dynamic > execution environments, where shared libraries, dynamically loaded > shared libraries, and runtime relocation of shared libraries are > supported, an mqs_image should represent the collection of image > files loaded into the address space of the MPI process at any given > point in time; in this situation, mqs_image may in fact represent > the MPI process itself. > > Cheers, John D. > > > Anh Vo wrote: > > > Thanks Kathryn for starting up the discussion. > > > > I'll start with my existing definition of mqs_image in the document, > which definitely is not adequate. > > > > Existing definition: > > An image is an executable file that was loaded into memory when > > a process is started. For SIMD-style programs, all MPI processes > have > > the same image. For MIMD-style programs, MPI processes might have > > different images. > > > > Dong's comments: > > The definition of "Image" isn't all that rigorous here. I think this > creates some confusion somewhere down this document. Is an image > really an executable file? Which typically means the base > executable or does this refer to both the based executable and DSOs > being loaded into the process address space? Though it sounds > hair-splitting, even the SPMD remark, the statement is only true if > the image is defined to be the base executable. > > > > John's comments: > > I think we should be more general with the term "image" to mean > executable or shared library. The reason is that we do not want to > require symbols to reside in the executable. We should allow symbols > to reside in shared libraries. > > Also, I think we need to define the "address space" of a process, > and an "image list" as a collection of image files that have been > loaded in the address space, and possibly relocated at runtime. > > > > I think I agree with both comments. Image should not refer to a > single executable image (a.out or a.exe), but rather the base > executable and the shared libraries that were loaded into the > process address space. > > > > So how about this new definition: > > An image represents the executable (e.g., a.out) and the collection > of dynamically loaded libraries that were loaded into the process > address space. > > > > --Anh > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of > *Kathryn Mohror > *Sent:* Tuesday, May 21, 2013 6:27 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi John, > > > > Thank you for the extensive feedback and help with the document! I'm > sure you will get the 'nod' you referred to on page 1 :-) > > > > For the definition of mqs_image, I agree that it needs work. Dong > Ahn also mentioned that it needed to be more rigorously defined. > However if possible, I think it would be beneficial if we could at > least start the conversation before next week so that we have a > better chance of having it nailed down in advance of the next meeting. > > > > So, that said -- does anyone want to take a first stab at a > definition to get us started? > > > > Kathryn > > > > On May 21, 2013, at 2:18 PM, John DelSignore > <John.DelSignore(a)roguewave.com <mailto:[email protected]> > <mailto:[email protected]>> > wrote: > > > > Hi, > > Attached are my edits and comments on the MPI Message Queue > document. Anh provided me with a Word document generated from the > LaTex, so the formatting is funky in some places. I enabled change > tracking in Word before making my edits, and I added many comments > to the document in places where I think we have more work to do. > Unfortunately, I think the changes might be somewhat extensive. > > The volume of edits and comments aside, I think Anh did a great job! > The first draft of the document closely reflects the 10+ year-old > description of the interface pretty well. Unfortunately, the > original interface has some problem that we need to resolve, most > critically, we have to resolve how to describe the concept of > "mqs_image". We can talk about this during the next concall. > > Cheers, John D. > > > Anh Vo wrote: > > Hi all, > > As mentioned on the tool WG call today, I'm re-sending the > latest draft. > Feedbacks are appreciated. We'll send this one out to the wider > audience > on Tuesday 5/21 to meet the requirement for first reading in > June > > > > --Anh > > <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > <msgq.pdf>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] latest draft of mqs
by John DelSignore 24 May '13

24 May '13

Thanks. I accidentally missed the definition of "Image File" in my first email, which I think should be: 3.6 Image File An image file is an executable or shared library file, which may contain symbol definitions needed by the MQD interface. And all of the later 3.x sections have to get renumbered, but I assume LaTex will do that for you automatically. Cheers, John D. -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Friday, May 24, 2013 12:26 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, I incorporated your edits into the current docs. Thank you! Attached is the chapter 3 with the new layout (each definition has its own section). Note that in the PDF I sent yesterday, each of the callback function in the mqs_basic_callbacks, mqs_image_callbacks, and mqs_process_callbacks also got it own subsection (based on Martin's feedbacks) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 8:58 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi Anh, I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. More later... Cheers, John D -----------------------cut-here--------------------------- Chapter 3 Definitions 3.1 Shared Library A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. 3.2 Shared Object File The term used on UNIX and UNIX-based systems to describe a shared library. 3.3 Dynamic-Link Library The term used on Windows and OS/2 systems to describe a shared library. 3.4 Dynamically Loaded Library A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. 3.5 DLL An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. 3.6 MPI Process An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. 3.7 Address Space An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. 3.8 "mqs_image" An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. 3.9 "Starter" Process Definition The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. 3.10 Host and Target Node Definitions For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. -----------------------cut-here--------------------------- -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Thursday, May 23, 2013 4:49 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, May 23, 2013 12:52 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. Cheers, John D. Anh Vo wrote: > Hi all, > > I have updated the MQS draft incorporating most of John's feedbacks. > There are still a few items here and there and I plan to get it done > by the end of today so we can send it out to the forum before Friday > noon as we promised. > > I'm sending this now since I need feedbacks on some of the new > definitions provided in chapter 3. Please look at Chapter 3. Note that > due to our definition of mqs_image, the document will use > \emph{mqs_image} in place of image (this is one part that I will go > through and make sure I change them). \variable{mqs_image} will be > used when referring to the type mqs_image of the interface. > > > > --Anh > > > > > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 2:16 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Comments inline > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 1:44 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi Ahn, > > > > comments inline: > > Page 2, Comment JD4 > John's comments about lots of hyphenated identifiers at end of line. > Some of it are artifacts of converting PDF -> Word, but I think this > is a common (and widely accepted) problems of latex documents. So we > will probably have to live with it unless there're some magic way to > make it nicer. > > > > I searched the standard (with PDF viewer search) and didn't see any > broken hyphenated identifiers at the ends of lines. I noted that in > the standard type and function names are like so: MPI\_COMM\_WORLD > while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If > you remove the \- will it do the right thing? I am not a Latex guru > so I don't know. > > [anhvo]: Yes, I think I mainly followed the practice of the latex in > MPIR and put the \- there, it basically tells Latex it can break off > the lines there. Not sure which one is more desirable? > > > > I don't care either way really, except I think it looks bad if words > go past the end of the margin if LaTeX doesn't know what to do with > the word. There's probably some magic to fix that but I don't know it. > > > > > > Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted > table similar to what the MPIR document had. For example: > > Char MPIR_dll_name[] > Definition is required > Definition is contained within the address space of the MPI process > Variable is written by the MPI process, and read by the tool > > I thought I did ask about this in the conf call at some point (or > maybe it was an email, I can't remember the exact time and place) and > we agreed that we would not be using that format because many people > in the forum thought it was weird looking. > > > > Well, my opinion is that it should be consistent with what is in MPIR > since it's supposed to be part of the same document. I don't remember > the 'weird looking' comment, but I wouldn't be surprised if someone made it. > > [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to > me. And I agreed with Jeff so I removed it. I might be in the minority > but I don't necessarily agree that we should have similar format with > the MPIR Document. They're both side documents but they're quite > different. In MPIR there are many variables so it's quite important to > mention where they should stay and who is writing, reading it. In MQS > we separate callbacks by debugger and DLL so it's quite clear who > should define what > > > > Maybe a compromise is to put this sort of information at the top of > each section.subsection that defines a set of variables? You already > say it in the text, but pulling it out somehow may be helpful to > people new to the interface. It's just an idea... I'm not married to it. > > > > Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at > the end of the typedef definition? When I first created the document, > I also debated a bit between this. I ended up following the style of > the MPI standard where it lists the C declaration without any ; I'm > fine either way, but would like to hear others' opinions on this. > > > > I think the standard does use ; . At least I didn't see any -- did I > miss what you mean? > > [anhvo]: The standard does not put semicolon after a C definition. > Randomly picking: page 38, C definition of MPI_BSend: > > int MPI_Bsend(...) (no semicolon at the end) > > > > Oh, yes I see what you mean. Okay, given that I would vote for no ; > > > > Kathryn > > > > > > Thanks for your hard work Ahn! > > Kathryn > > > > > I'm leaving for lunch now. More comments after I'm back. In the > meantime, if folks can comments on what I've sent so far, that'd be > great!! > > Thanks > Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Anh Vo > Sent: Wednesday, May 22, 2013 8:10 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > The definitions John provide look great for me. Unless there are > other opinions, I will use those. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Ahn, Dong H. > Sent: Wednesday, May 22, 2013 7:54 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > > This works for me and should clarify a few things in the current draft. > > Best, > Dong > > > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John > DelSignore > Sent: Wednesday, May 22, 2013 9:55 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > I prefer to not muddy up the "standard definitions" (or maybe > "common-sense definitions") of commonly used term, such as "image > file", to make them conform to the MQD interface. Instead, I like to > define the MQD typedefs in terms of the standard definitions. So, > WRT to the document, I think we should include the following > definitions: > > * An "image file" is an executable or shared library file, that may > contain symbol definitions needed by the MQD interface. > > * An "MPI process" consists of an "address space" and a collection > of execution contexts (threads or lightweight processes). > > * An "address space" is a region of memory that consists of executable > code and data, and is partially composed of a collection of image > files. The collection of image files may change at any point during > the execution of the MPI process, and image files may be relocated > at runtime within the address space at the point they are loaded > into memory. > > Then we can say: > > * An "mqs_image" is an abstract concept that represents the collection > of image files loaded into the address space of the MPI process at any > given time, and is debugger implementation defined. In static > execution environments, where shared libraries are not supported, an > mqs_image can represent an executable image file. However, in dynamic > execution environments, where shared libraries, dynamically loaded > shared libraries, and runtime relocation of shared libraries are > supported, an mqs_image should represent the collection of image > files loaded into the address space of the MPI process at any given > point in time; in this situation, mqs_image may in fact represent > the MPI process itself. > > Cheers, John D. > > > Anh Vo wrote: > > > Thanks Kathryn for starting up the discussion. > > > > I'll start with my existing definition of mqs_image in the document, > which definitely is not adequate. > > > > Existing definition: > > An image is an executable file that was loaded into memory when > > a process is started. For SIMD-style programs, all MPI processes > have > > the same image. For MIMD-style programs, MPI processes might have > > different images. > > > > Dong's comments: > > The definition of "Image" isn't all that rigorous here. I think this > creates some confusion somewhere down this document. Is an image > really an executable file? Which typically means the base > executable or does this refer to both the based executable and DSOs > being loaded into the process address space? Though it sounds > hair-splitting, even the SPMD remark, the statement is only true if > the image is defined to be the base executable. > > > > John's comments: > > I think we should be more general with the term "image" to mean > executable or shared library. The reason is that we do not want to > require symbols to reside in the executable. We should allow symbols > to reside in shared libraries. > > Also, I think we need to define the "address space" of a process, > and an "image list" as a collection of image files that have been > loaded in the address space, and possibly relocated at runtime. > > > > I think I agree with both comments. Image should not refer to a > single executable image (a.out or a.exe), but rather the base > executable and the shared libraries that were loaded into the > process address space. > > > > So how about this new definition: > > An image represents the executable (e.g., a.out) and the collection > of dynamically loaded libraries that were loaded into the process > address space. > > > > --Anh > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of > *Kathryn Mohror > *Sent:* Tuesday, May 21, 2013 6:27 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi John, > > > > Thank you for the extensive feedback and help with the document! I'm > sure you will get the 'nod' you referred to on page 1 :-) > > > > For the definition of mqs_image, I agree that it needs work. Dong > Ahn also mentioned that it needed to be more rigorously defined. > However if possible, I think it would be beneficial if we could at > least start the conversation before next week so that we have a > better chance of having it nailed down in advance of the next meeting. > > > > So, that said -- does anyone want to take a first stab at a > definition to get us started? > > > > Kathryn > > > > On May 21, 2013, at 2:18 PM, John DelSignore > <John.DelSignore(a)roguewave.com <mailto:[email protected]> > <mailto:[email protected]>> > wrote: > > > > Hi, > > Attached are my edits and comments on the MPI Message Queue > document. Anh provided me with a Word document generated from the > LaTex, so the formatting is funky in some places. I enabled change > tracking in Word before making my edits, and I added many comments > to the document in places where I think we have more work to do. > Unfortunately, I think the changes might be somewhat extensive. > > The volume of edits and comments aside, I think Anh did a great job! > The first draft of the document closely reflects the 10+ year-old > description of the interface pretty well. Unfortunately, the > original interface has some problem that we need to resolve, most > critically, we have to resolve how to describe the concept of > "mqs_image". We can talk about this during the next concall. > > Cheers, John D. > > > Anh Vo wrote: > > Hi all, > > As mentioned on the tool WG call today, I'm re-sending the > latest draft. > Feedbacks are appreciated. We'll send this one out to the wider > audience > on Tuesday 5/21 to meet the requirement for first reading in > June > > > > --Anh > > <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > <msgq.pdf>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] latest draft of mqs
by Anh Vo 24 May '13

24 May '13

Hi John, I incorporated your edits into the current docs. Thank you! Attached is the chapter 3 with the new layout (each definition has its own section). Note that in the PDF I sent yesterday, each of the callback function in the mqs_basic_callbacks, mqs_image_callbacks, and mqs_process_callbacks also got it own subsection (based on Martin's feedbacks) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Friday, May 24, 2013 8:58 AM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi Anh, I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. More later... Cheers, John D -----------------------cut-here--------------------------- Chapter 3 Definitions 3.1 Shared Library A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. 3.2 Shared Object File The term used on UNIX and UNIX-based systems to describe a shared library. 3.3 Dynamic-Link Library The term used on Windows and OS/2 systems to describe a shared library. 3.4 Dynamically Loaded Library A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. 3.5 DLL An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. 3.6 MPI Process An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. 3.7 Address Space An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. 3.8 "mqs_image" An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. 3.9 "Starter" Process Definition The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. 3.10 Host and Target Node Definitions For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. -----------------------cut-here--------------------------- -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Thursday, May 23, 2013 4:49 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, May 23, 2013 12:52 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. Cheers, John D. Anh Vo wrote: > Hi all, > > I have updated the MQS draft incorporating most of John's feedbacks. > There are still a few items here and there and I plan to get it done > by the end of today so we can send it out to the forum before Friday > noon as we promised. > > I'm sending this now since I need feedbacks on some of the new > definitions provided in chapter 3. Please look at Chapter 3. Note that > due to our definition of mqs_image, the document will use > \emph{mqs_image} in place of image (this is one part that I will go > through and make sure I change them). \variable{mqs_image} will be > used when referring to the type mqs_image of the interface. > > > > --Anh > > > > > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 2:16 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Comments inline > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 1:44 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi Ahn, > > > > comments inline: > > Page 2, Comment JD4 > John's comments about lots of hyphenated identifiers at end of line. > Some of it are artifacts of converting PDF -> Word, but I think this > is a common (and widely accepted) problems of latex documents. So we > will probably have to live with it unless there're some magic way to > make it nicer. > > > > I searched the standard (with PDF viewer search) and didn't see any > broken hyphenated identifiers at the ends of lines. I noted that in > the standard type and function names are like so: MPI\_COMM\_WORLD > while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If > you remove the \- will it do the right thing? I am not a Latex guru > so I don't know. > > [anhvo]: Yes, I think I mainly followed the practice of the latex in > MPIR and put the \- there, it basically tells Latex it can break off > the lines there. Not sure which one is more desirable? > > > > I don't care either way really, except I think it looks bad if words > go past the end of the margin if LaTeX doesn't know what to do with > the word. There's probably some magic to fix that but I don't know it. > > > > > > Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted > table similar to what the MPIR document had. For example: > > Char MPIR_dll_name[] > Definition is required > Definition is contained within the address space of the MPI process > Variable is written by the MPI process, and read by the tool > > I thought I did ask about this in the conf call at some point (or > maybe it was an email, I can't remember the exact time and place) and > we agreed that we would not be using that format because many people > in the forum thought it was weird looking. > > > > Well, my opinion is that it should be consistent with what is in MPIR > since it's supposed to be part of the same document. I don't remember > the 'weird looking' comment, but I wouldn't be surprised if someone made it. > > [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to > me. And I agreed with Jeff so I removed it. I might be in the minority > but I don't necessarily agree that we should have similar format with > the MPIR Document. They're both side documents but they're quite > different. In MPIR there are many variables so it's quite important to > mention where they should stay and who is writing, reading it. In MQS > we separate callbacks by debugger and DLL so it's quite clear who > should define what > > > > Maybe a compromise is to put this sort of information at the top of > each section.subsection that defines a set of variables? You already > say it in the text, but pulling it out somehow may be helpful to > people new to the interface. It's just an idea... I'm not married to it. > > > > Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at > the end of the typedef definition? When I first created the document, > I also debated a bit between this. I ended up following the style of > the MPI standard where it lists the C declaration without any ; I'm > fine either way, but would like to hear others' opinions on this. > > > > I think the standard does use ; . At least I didn't see any -- did I > miss what you mean? > > [anhvo]: The standard does not put semicolon after a C definition. > Randomly picking: page 38, C definition of MPI_BSend: > > int MPI_Bsend(...) (no semicolon at the end) > > > > Oh, yes I see what you mean. Okay, given that I would vote for no ; > > > > Kathryn > > > > > > Thanks for your hard work Ahn! > > Kathryn > > > > > I'm leaving for lunch now. More comments after I'm back. In the > meantime, if folks can comments on what I've sent so far, that'd be > great!! > > Thanks > Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Anh Vo > Sent: Wednesday, May 22, 2013 8:10 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > The definitions John provide look great for me. Unless there are > other opinions, I will use those. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Ahn, Dong H. > Sent: Wednesday, May 22, 2013 7:54 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > > This works for me and should clarify a few things in the current draft. > > Best, > Dong > > > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John > DelSignore > Sent: Wednesday, May 22, 2013 9:55 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > I prefer to not muddy up the "standard definitions" (or maybe > "common-sense definitions") of commonly used term, such as "image > file", to make them conform to the MQD interface. Instead, I like to > define the MQD typedefs in terms of the standard definitions. So, > WRT to the document, I think we should include the following > definitions: > > * An "image file" is an executable or shared library file, that may > contain symbol definitions needed by the MQD interface. > > * An "MPI process" consists of an "address space" and a collection > of execution contexts (threads or lightweight processes). > > * An "address space" is a region of memory that consists of executable > code and data, and is partially composed of a collection of image > files. The collection of image files may change at any point during > the execution of the MPI process, and image files may be relocated > at runtime within the address space at the point they are loaded > into memory. > > Then we can say: > > * An "mqs_image" is an abstract concept that represents the collection > of image files loaded into the address space of the MPI process at any > given time, and is debugger implementation defined. In static > execution environments, where shared libraries are not supported, an > mqs_image can represent an executable image file. However, in dynamic > execution environments, where shared libraries, dynamically loaded > shared libraries, and runtime relocation of shared libraries are > supported, an mqs_image should represent the collection of image > files loaded into the address space of the MPI process at any given > point in time; in this situation, mqs_image may in fact represent > the MPI process itself. > > Cheers, John D. > > > Anh Vo wrote: > > > Thanks Kathryn for starting up the discussion. > > > > I'll start with my existing definition of mqs_image in the document, > which definitely is not adequate. > > > > Existing definition: > > An image is an executable file that was loaded into memory when > > a process is started. For SIMD-style programs, all MPI processes > have > > the same image. For MIMD-style programs, MPI processes might have > > different images. > > > > Dong's comments: > > The definition of "Image" isn't all that rigorous here. I think this > creates some confusion somewhere down this document. Is an image > really an executable file? Which typically means the base > executable or does this refer to both the based executable and DSOs > being loaded into the process address space? Though it sounds > hair-splitting, even the SPMD remark, the statement is only true if > the image is defined to be the base executable. > > > > John's comments: > > I think we should be more general with the term "image" to mean > executable or shared library. The reason is that we do not want to > require symbols to reside in the executable. We should allow symbols > to reside in shared libraries. > > Also, I think we need to define the "address space" of a process, > and an "image list" as a collection of image files that have been > loaded in the address space, and possibly relocated at runtime. > > > > I think I agree with both comments. Image should not refer to a > single executable image (a.out or a.exe), but rather the base > executable and the shared libraries that were loaded into the > process address space. > > > > So how about this new definition: > > An image represents the executable (e.g., a.out) and the collection > of dynamically loaded libraries that were loaded into the process > address space. > > > > --Anh > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of > *Kathryn Mohror > *Sent:* Tuesday, May 21, 2013 6:27 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi John, > > > > Thank you for the extensive feedback and help with the document! I'm > sure you will get the 'nod' you referred to on page 1 :-) > > > > For the definition of mqs_image, I agree that it needs work. Dong > Ahn also mentioned that it needed to be more rigorously defined. > However if possible, I think it would be beneficial if we could at > least start the conversation before next week so that we have a > better chance of having it nailed down in advance of the next meeting. > > > > So, that said -- does anyone want to take a first stab at a > definition to get us started? > > > > Kathryn > > > > On May 21, 2013, at 2:18 PM, John DelSignore > <John.DelSignore(a)roguewave.com <mailto:[email protected]> > <mailto:[email protected]>> > wrote: > > > > Hi, > > Attached are my edits and comments on the MPI Message Queue > document. Anh provided me with a Word document generated from the > LaTex, so the formatting is funky in some places. I enabled change > tracking in Word before making my edits, and I added many comments > to the document in places where I think we have more work to do. > Unfortunately, I think the changes might be somewhat extensive. > > The volume of edits and comments aside, I think Anh did a great job! > The first draft of the document closely reflects the 10+ year-old > description of the interface pretty well. Unfortunately, the > original interface has some problem that we need to resolve, most > critically, we have to resolve how to describe the concept of > "mqs_image". We can talk about this during the next concall. > > Cheers, John D. > > > Anh Vo wrote: > > Hi all, > > As mentioned on the tool WG call today, I'm re-sending the > latest draft. > Feedbacks are appreciated. We'll send this one out to the wider > audience > on Tuesday 5/21 to meet the requirement for first reading in > June > > > > --Anh > > <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > <msgq.pdf>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] latest draft of mqs
by John DelSignore 24 May '13

24 May '13

Hi Anh, I've been working on the latest version of the document you sent last night, but I thought I'd send you my edits to the Definitions section as you requested. I copied/pasted the prose of the definitions below, which will also be included in the marked-up Word document (I'll try to finish that today and send it to you by COB EDT). I don't have strong feelings on the formatting or section layout of the definitions section, but I do think that each term we define should have its own "subsection" or be grouped separately. Below, I used the heading conventions used in the MPIR Process Acquisition document, and gave each definition its own subsection. More later... Cheers, John D -----------------------cut-here--------------------------- Chapter 3 Definitions 3.1 Shared Library A shared library or shared object is a file that is intended to be shared by executable files and other shared libraries. Shared libraries may be relocated at runtime, and may be dynamically loaded at runtime. 3.2 Shared Object File The term used on UNIX and UNIX-based systems to describe a shared library. 3.3 Dynamic-Link Library The term used on Windows and OS/2 systems to describe a shared library. 3.4 Dynamically Loaded Library A shared library that can be loaded and unloaded at runtime on request by calling dlopen, dlclose, dlsym on UNIX and UNIX-like systems, or LoadLibrary, FreeLibrary, GetProcAddress on Windows systems. Debuggers require the dynamic loading of the MQD shared library to provide MQD support. 3.5 DLL An overloaded term that refers to either a dynamic-link library, dynamically loaded library, or shared library. 3.6 MPI Process An MPI process, or simply "process" in the scope of this document, is defined to be an operating system (OS) process, which consists of an address space and a collection of execution contexts (threads or lightweight processes). The MPI process is part of the MPI application as described in the MPI standard. While the standard does not require that an MPI process be an OS process, this is a requirement for most debuggers and this interface was designed with that assumption. 3.7 Address Space An address space is a region of memory that consists of executable code and data, and is partially composed of a collection of image files. The collection of image files may change at any point during the execution of the MPI process, and the image files may be relocated at runtime within the address space at the point they are loaded into memory. 3.8 "mqs_image" An mqs_image, or sometimes simply referred to as an "image" in this document, is an abstract concept that represents the collection of image files loaded into the address space of the MPI process at any given time. The underlying object represented by an mqs_image is debugger implementation defined. In static execution environments, where shared libraries are not supported, an mqs_image might represent an executable image file. However, in dynamic execution environments, where shared libraries, dynamically loaded shared libraries, and runtime relocation of shared libraries are supported, an mqs_image might represent the collection of image files loaded into the address space of the MPI process at any given point in time. In this situation mqs_image might in fact represent the MPI process itself. 3.9 "Starter" Process Definition The starter process is the process that is responsible for launching the MPI job. The starter process may be a separate process that is not part of the MPI application, or any MPI process may act as a starter process. By definition, the starter process contains functions, data structures, and symbol table information for the MPIR Process Acquisition Interface. See the MPIR Process Acquisition Interface for more details. 3.10 Host and Target Node Definitions For the purposes of this document, the host node is defined to be the node running the tool process, and a target node is defined to be a node running the target application processes the tool is controlling. A target node might also be the host node; that is, the target application processes might be running on the same node as the tool process. -----------------------cut-here--------------------------- -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo Sent: Thursday, May 23, 2013 4:49 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Hi John, Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, May 23, 2013 12:52 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] latest draft of mqs Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. Cheers, John D. Anh Vo wrote: > Hi all, > > I have updated the MQS draft incorporating most of John's feedbacks. > There are still a few items here and there and I plan to get it done > by the end of today so we can send it out to the forum before Friday > noon as we promised. > > I'm sending this now since I need feedbacks on some of the new > definitions provided in chapter 3. Please look at Chapter 3. Note that > due to our definition of mqs_image, the document will use > \emph{mqs_image} in place of image (this is one part that I will go > through and make sure I change them). \variable{mqs_image} will be > used when referring to the type mqs_image of the interface. > > > > --Anh > > > > > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 2:16 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Comments inline > > > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of *Kathryn > Mohror > *Sent:* Wednesday, May 22, 2013 1:44 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi Ahn, > > > > comments inline: > > Page 2, Comment JD4 > John's comments about lots of hyphenated identifiers at end of line. > Some of it are artifacts of converting PDF -> Word, but I think this > is a common (and widely accepted) problems of latex documents. So we > will probably have to live with it unless there're some magic way to > make it nicer. > > > > I searched the standard (with PDF viewer search) and didn't see any > broken hyphenated identifiers at the ends of lines. I noted that in > the standard type and function names are like so: MPI\_COMM\_WORLD > while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If > you remove the \- will it do the right thing? I am not a Latex guru > so I don't know. > > [anhvo]: Yes, I think I mainly followed the practice of the latex in > MPIR and put the \- there, it basically tells Latex it can break off > the lines there. Not sure which one is more desirable? > > > > I don't care either way really, except I think it looks bad if words > go past the end of the margin if LaTeX doesn't know what to do with > the word. There's probably some magic to fix that but I don't know it. > > > > > > Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted > table similar to what the MPIR document had. For example: > > Char MPIR_dll_name[] > Definition is required > Definition is contained within the address space of the MPI process > Variable is written by the MPI process, and read by the tool > > I thought I did ask about this in the conf call at some point (or > maybe it was an email, I can't remember the exact time and place) and > we agreed that we would not be using that format because many people > in the forum thought it was weird looking. > > > > Well, my opinion is that it should be consistent with what is in MPIR > since it's supposed to be part of the same document. I don't remember > the 'weird looking' comment, but I wouldn't be surprised if someone made it. > > [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to > me. And I agreed with Jeff so I removed it. I might be in the minority > but I don't necessarily agree that we should have similar format with > the MPIR Document. They're both side documents but they're quite > different. In MPIR there are many variables so it's quite important to > mention where they should stay and who is writing, reading it. In MQS > we separate callbacks by debugger and DLL so it's quite clear who > should define what > > > > Maybe a compromise is to put this sort of information at the top of > each section.subsection that defines a set of variables? You already > say it in the text, but pulling it out somehow may be helpful to > people new to the interface. It's just an idea... I'm not married to it. > > > > Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at > the end of the typedef definition? When I first created the document, > I also debated a bit between this. I ended up following the style of > the MPI standard where it lists the C declaration without any ; I'm > fine either way, but would like to hear others' opinions on this. > > > > I think the standard does use ; . At least I didn't see any -- did I > miss what you mean? > > [anhvo]: The standard does not put semicolon after a C definition. > Randomly picking: page 38, C definition of MPI_BSend: > > int MPI_Bsend(...) (no semicolon at the end) > > > > Oh, yes I see what you mean. Okay, given that I would vote for no ; > > > > Kathryn > > > > > > Thanks for your hard work Ahn! > > Kathryn > > > > > I'm leaving for lunch now. More comments after I'm back. In the > meantime, if folks can comments on what I've sent so far, that'd be > great!! > > Thanks > Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Anh Vo > Sent: Wednesday, May 22, 2013 8:10 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > The definitions John provide look great for me. Unless there are > other opinions, I will use those. > > --Anh > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Ahn, Dong H. > Sent: Wednesday, May 22, 2013 7:54 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > Hi John, > > This works for me and should clarify a few things in the current draft. > > Best, > Dong > > > > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John > DelSignore > Sent: Wednesday, May 22, 2013 9:55 AM > To: mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > Subject: Re: [Mpi3-tools] latest draft of mqs > > I prefer to not muddy up the "standard definitions" (or maybe > "common-sense definitions") of commonly used term, such as "image > file", to make them conform to the MQD interface. Instead, I like to > define the MQD typedefs in terms of the standard definitions. So, > WRT to the document, I think we should include the following > definitions: > > * An "image file" is an executable or shared library file, that may > contain symbol definitions needed by the MQD interface. > > * An "MPI process" consists of an "address space" and a collection > of execution contexts (threads or lightweight processes). > > * An "address space" is a region of memory that consists of executable > code and data, and is partially composed of a collection of image > files. The collection of image files may change at any point during > the execution of the MPI process, and image files may be relocated > at runtime within the address space at the point they are loaded > into memory. > > Then we can say: > > * An "mqs_image" is an abstract concept that represents the collection > of image files loaded into the address space of the MPI process at any > given time, and is debugger implementation defined. In static > execution environments, where shared libraries are not supported, an > mqs_image can represent an executable image file. However, in dynamic > execution environments, where shared libraries, dynamically loaded > shared libraries, and runtime relocation of shared libraries are > supported, an mqs_image should represent the collection of image > files loaded into the address space of the MPI process at any given > point in time; in this situation, mqs_image may in fact represent > the MPI process itself. > > Cheers, John D. > > > Anh Vo wrote: > > > Thanks Kathryn for starting up the discussion. > > > > I'll start with my existing definition of mqs_image in the document, > which definitely is not adequate. > > > > Existing definition: > > An image is an executable file that was loaded into memory when > > a process is started. For SIMD-style programs, all MPI processes > have > > the same image. For MIMD-style programs, MPI processes might have > > different images. > > > > Dong's comments: > > The definition of "Image" isn't all that rigorous here. I think this > creates some confusion somewhere down this document. Is an image > really an executable file? Which typically means the base > executable or does this refer to both the based executable and DSOs > being loaded into the process address space? Though it sounds > hair-splitting, even the SPMD remark, the statement is only true if > the image is defined to be the base executable. > > > > John's comments: > > I think we should be more general with the term "image" to mean > executable or shared library. The reason is that we do not want to > require symbols to reside in the executable. We should allow symbols > to reside in shared libraries. > > Also, I think we need to define the "address space" of a process, > and an "image list" as a collection of image files that have been > loaded in the address space, and possibly relocated at runtime. > > > > I think I agree with both comments. Image should not refer to a > single executable image (a.out or a.exe), but rather the base > executable and the shared libraries that were loaded into the > process address space. > > > > So how about this new definition: > > An image represents the executable (e.g., a.out) and the collection > of dynamically loaded libraries that were loaded into the process > address space. > > > > --Anh > > *From:* mpi3-tools-bounces(a)lists.mpi-forum.org > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] *On Behalf Of > *Kathryn Mohror > *Sent:* Tuesday, May 21, 2013 6:27 PM > *To:* mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> > *Subject:* Re: [Mpi3-tools] latest draft of mqs > > > > Hi John, > > > > Thank you for the extensive feedback and help with the document! I'm > sure you will get the 'nod' you referred to on page 1 :-) > > > > For the definition of mqs_image, I agree that it needs work. Dong > Ahn also mentioned that it needed to be more rigorously defined. > However if possible, I think it would be beneficial if we could at > least start the conversation before next week so that we have a > better chance of having it nailed down in advance of the next meeting. > > > > So, that said -- does anyone want to take a first stab at a > definition to get us started? > > > > Kathryn > > > > On May 21, 2013, at 2:18 PM, John DelSignore > <John.DelSignore(a)roguewave.com <mailto:[email protected]> > <mailto:[email protected]>> > wrote: > > > > Hi, > > Attached are my edits and comments on the MPI Message Queue > document. Anh provided me with a Word document generated from the > LaTex, so the formatting is funky in some places. I enabled change > tracking in Word before making my edits, and I added many comments > to the document in places where I think we have more work to do. > Unfortunately, I think the changes might be somewhat extensive. > > The volume of edits and comments aside, I think Anh did a great job! > The first draft of the document closely reflects the 10+ year-old > description of the interface pretty well. Unfortunately, the > original interface has some problem that we need to resolve, most > critically, we have to resolve how to describe the concept of > "mqs_image". We can talk about this during the next concall. > > Cheers, John D. > > > Anh Vo wrote: > > Hi all, > > As mentioned on the tool WG call today, I'm re-sending the > latest draft. > Feedbacks are appreciated. We'll send this one out to the wider > audience > on Tuesday 5/21 to meet the requirement for first reading in > June > > > > --Anh > > <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > <mailto:[email protected]> <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > <msgq.pdf>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov > <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ > Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] latest draft of mqs
by John DelSignore 24 May '13

24 May '13

The conversion falls into the category of, "good enough for what we need"... the tool does a fairly decent job at preserving the prose and structure of the document, which is all that's needed for markup. The last time we did this: 1) Anh (easily) converted the document to Word and sent it to me (I suppose I could have done that myself). 2) I turned on Word's change tracking, made my edits, and added comments to the document. 3) I sent it back to Anh. 4) He used Word (or functional equivalent) to walk through my edits/comments applying them to the LaTex master. Since my edits/comments are in Word, and not on paper like Jeff S's, Anh could copy and paste them from the Word document into the LaTex document. All in all, I think it worked well. Cheers, John D. Jeff Hammond wrote: > My recollection of the 'worst idea ever' included attempts at using > website-based conversion tools such as this one. The MPI documents > must be easier to convert due to lack of images and equations, because > they didn't help my cause any more than good old fashioned text-based > copy-and-paste + redo everything that isn't raw ASCII. > > Jeff > > On Thu, May 23, 2013 at 8:30 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com> wrote: >> Jeff -- >> >> I think we got trumped by http://www.pdftoword.com/. :-) >> >> >> On May 23, 2013, at 9:11 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: >> >>> In order words, what Squyres is trying to say that the original is >>> written in LaTeX, not Word, and thus editing it natively requires >>> LaTeX expertise, and not just the usual level, since MPI standard >>> documents use lots of voodoo that may or may not have been invented by >>> Bill Gropp, who is master of software voodoo* :-) >>> >>> * e.g. http://www.cs.uiuc.edu/homes/wgropp/projects/software/sowing/index.htm >>> >>> Having tried once to co-mingle Word and LaTeX authoring (the joys of >>> interdisciplinary proposal writing), I can say without any hesitation >>> that this is the worst idea ever. I have never hated myself more than >>> the weekend I had to merge a LaTeX-generated PDF and a Word document, >>> including two distinct and very long bibliographies in their respect >>> native formats. >>> >>> Jeff >>> >>> On Thu, May 23, 2013 at 7:59 PM, Jeff Squyres (jsquyres) >>> <jsquyres(a)cisco.com> wrote: >>>> John -- >>>> >>>> FWIW: what I did to send edits was to print out the PDF, write out my edits, scan in the pages, and send the resulting scan-PDF to Ahn. >>>> >>>> That might save Ahn a lot of time compared to transcribing the whole document to Word...? >>>> >>>> >>>> >>>> On May 23, 2013, at 8:09 PM, John DelSignore <John.DelSignore(a)roguewave.com> >>>> wrote: >>>> >>>>> Hi Anh, >>>>> >>>>> Could you please send the Word version of the document too? >>>>> >>>>> Thanks, John D. >>>>> >>>>> >>>>> Anh Vo wrote: >>>>>> Hi all, >>>>>> I'm done with my edits. Attached is the latest draft. The latex is also checked in. >>>>>> >>>>>> --Anh >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo >>>>>> Sent: Thursday, May 23, 2013 1:49 PM >>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> Hi John, >>>>>> Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. >>>>>> >>>>>> The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) >>>>>> >>>>>> --Anh >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore >>>>>> Sent: Thursday, May 23, 2013 12:52 PM >>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. >>>>>> >>>>>> One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. >>>>>> >>>>>> Cheers, John D. >>>>>> >>>>>> >>>>>> Anh Vo wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I have updated the MQS draft incorporating most of John's feedbacks. >>>>>>> There are still a few items here and there and I plan to get it done >>>>>>> by the end of today so we can send it out to the forum before Friday >>>>>>> noon as we promised. >>>>>>> >>>>>>> I'm sending this now since I need feedbacks on some of the new >>>>>>> definitions provided in chapter 3. Please look at Chapter 3. Note that >>>>>>> due to our definition of mqs_image, the document will use >>>>>>> \emph{mqs_image} in place of image (this is one part that I will go >>>>>>> through and make sure I change them). \variable{mqs_image} will be >>>>>>> used when referring to the type mqs_image of the interface. >>>>>>> >>>>>>> >>>>>>> >>>>>>> --Anh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> [mailto:[email protected]] *On Behalf Of *Kathryn >>>>>>> Mohror >>>>>>> *Sent:* Wednesday, May 22, 2013 2:16 PM >>>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> >>>>>>> >>>>>>> Comments inline >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>>> <mailto:[email protected]>] *On Behalf Of *Kathryn >>>>>>> Mohror >>>>>>> *Sent:* Wednesday, May 22, 2013 1:44 PM >>>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Ahn, >>>>>>> >>>>>>> >>>>>>> >>>>>>> comments inline: >>>>>>> >>>>>>> Page 2, Comment JD4 >>>>>>> John's comments about lots of hyphenated identifiers at end of line. >>>>>>> Some of it are artifacts of converting PDF -> Word, but I think this >>>>>>> is a common (and widely accepted) problems of latex documents. So we >>>>>>> will probably have to live with it unless there're some magic way to >>>>>>> make it nicer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I searched the standard (with PDF viewer search) and didn't see any >>>>>>> broken hyphenated identifiers at the ends of lines. I noted that in >>>>>>> the standard type and function names are like so: MPI\_COMM\_WORLD >>>>>>> while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If >>>>>>> you remove the \- will it do the right thing? I am not a Latex guru >>>>>>> so I don't know. >>>>>>> >>>>>>> [anhvo]: Yes, I think I mainly followed the practice of the latex in >>>>>>> MPIR and put the \- there, it basically tells Latex it can break off >>>>>>> the lines there. Not sure which one is more desirable? >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't care either way really, except I think it looks bad if words >>>>>>> go past the end of the margin if LaTeX doesn't know what to do with >>>>>>> the word. There's probably some magic to fix that but I don't know it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted >>>>>>> table similar to what the MPIR document had. For example: >>>>>>> >>>>>>> Char MPIR_dll_name[] >>>>>>> Definition is required >>>>>>> Definition is contained within the address space of the MPI process >>>>>>> Variable is written by the MPI process, and read by the tool >>>>>>> >>>>>>> I thought I did ask about this in the conf call at some point (or >>>>>>> maybe it was an email, I can't remember the exact time and place) and >>>>>>> we agreed that we would not be using that format because many people >>>>>>> in the forum thought it was weird looking. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well, my opinion is that it should be consistent with what is in MPIR >>>>>>> since it's supposed to be part of the same document. I don't remember >>>>>>> the 'weird looking' comment, but I wouldn't be surprised if someone made it. >>>>>>> >>>>>>> [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to >>>>>>> me. And I agreed with Jeff so I removed it. I might be in the minority >>>>>>> but I don't necessarily agree that we should have similar format with >>>>>>> the MPIR Document. They're both side documents but they're quite >>>>>>> different. In MPIR there are many variables so it's quite important to >>>>>>> mention where they should stay and who is writing, reading it. In MQS >>>>>>> we separate callbacks by debugger and DLL so it's quite clear who >>>>>>> should define what >>>>>>> >>>>>>> >>>>>>> >>>>>>> Maybe a compromise is to put this sort of information at the top of >>>>>>> each section.subsection that defines a set of variables? You already >>>>>>> say it in the text, but pulling it out somehow may be helpful to >>>>>>> people new to the interface. It's just an idea... I'm not married to it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at >>>>>>> the end of the typedef definition? When I first created the document, >>>>>>> I also debated a bit between this. I ended up following the style of >>>>>>> the MPI standard where it lists the C declaration without any ; I'm >>>>>>> fine either way, but would like to hear others' opinions on this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think the standard does use ; . At least I didn't see any -- did I >>>>>>> miss what you mean? >>>>>>> >>>>>>> [anhvo]: The standard does not put semicolon after a C definition. >>>>>>> Randomly picking: page 38, C definition of MPI_BSend: >>>>>>> >>>>>>> int MPI_Bsend(...) (no semicolon at the end) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Oh, yes I see what you mean. Okay, given that I would vote for no ; >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kathryn >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for your hard work Ahn! >>>>>>> >>>>>>> Kathryn >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm leaving for lunch now. More comments after I'm back. In the >>>>>>> meantime, if folks can comments on what I've sent so far, that'd be >>>>>>> great!! >>>>>>> >>>>>>> Thanks >>>>>>> Anh >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>>> <mailto:[email protected]>] On Behalf Of Anh Vo >>>>>>> Sent: Wednesday, May 22, 2013 8:10 AM >>>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> The definitions John provide look great for me. Unless there are >>>>>>> other opinions, I will use those. >>>>>>> >>>>>>> --Anh >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>>> <mailto:[email protected]>] On Behalf Of Ahn, Dong H. >>>>>>> Sent: Wednesday, May 22, 2013 7:54 AM >>>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> This works for me and should clarify a few things in the current draft. >>>>>>> >>>>>>> Best, >>>>>>> Dong >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> [mailto:[email protected] >>>>>>> <mailto:[email protected]>] On Behalf Of John >>>>>>> DelSignore >>>>>>> Sent: Wednesday, May 22, 2013 9:55 AM >>>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> I prefer to not muddy up the "standard definitions" (or maybe >>>>>>> "common-sense definitions") of commonly used term, such as "image >>>>>>> file", to make them conform to the MQD interface. Instead, I like to >>>>>>> define the MQD typedefs in terms of the standard definitions. So, >>>>>>> WRT to the document, I think we should include the following >>>>>>> definitions: >>>>>>> >>>>>>> * An "image file" is an executable or shared library file, that may >>>>>>> contain symbol definitions needed by the MQD interface. >>>>>>> >>>>>>> * An "MPI process" consists of an "address space" and a collection >>>>>>> of execution contexts (threads or lightweight processes). >>>>>>> >>>>>>> * An "address space" is a region of memory that consists of executable >>>>>>> code and data, and is partially composed of a collection of image >>>>>>> files. The collection of image files may change at any point during >>>>>>> the execution of the MPI process, and image files may be relocated >>>>>>> at runtime within the address space at the point they are loaded >>>>>>> into memory. >>>>>>> >>>>>>> Then we can say: >>>>>>> >>>>>>> * An "mqs_image" is an abstract concept that represents the collection >>>>>>> of image files loaded into the address space of the MPI process at any >>>>>>> given time, and is debugger implementation defined. In static >>>>>>> execution environments, where shared libraries are not supported, an >>>>>>> mqs_image can represent an executable image file. However, in dynamic >>>>>>> execution environments, where shared libraries, dynamically loaded >>>>>>> shared libraries, and runtime relocation of shared libraries are >>>>>>> supported, an mqs_image should represent the collection of image >>>>>>> files loaded into the address space of the MPI process at any given >>>>>>> point in time; in this situation, mqs_image may in fact represent >>>>>>> the MPI process itself. >>>>>>> >>>>>>> Cheers, John D. >>>>>>> >>>>>>> >>>>>>> Anh Vo wrote: >>>>>>> >>>>>>> >>>>>>> Thanks Kathryn for starting up the discussion. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'll start with my existing definition of mqs_image in the document, >>>>>>> which definitely is not adequate. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Existing definition: >>>>>>> >>>>>>> An image is an executable file that was loaded into memory when >>>>>>> >>>>>>> a process is started. For SIMD-style programs, all MPI processes >>>>>>> have >>>>>>> >>>>>>> the same image. For MIMD-style programs, MPI processes might have >>>>>>> >>>>>>> different images. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dong's comments: >>>>>>> >>>>>>> The definition of "Image" isn't all that rigorous here. I think this >>>>>>> creates some confusion somewhere down this document. Is an image >>>>>>> really an executable file? Which typically means the base >>>>>>> executable or does this refer to both the based executable and DSOs >>>>>>> being loaded into the process address space? Though it sounds >>>>>>> hair-splitting, even the SPMD remark, the statement is only true if >>>>>>> the image is defined to be the base executable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> John's comments: >>>>>>> >>>>>>> I think we should be more general with the term "image" to mean >>>>>>> executable or shared library. The reason is that we do not want to >>>>>>> require symbols to reside in the executable. We should allow symbols >>>>>>> to reside in shared libraries. >>>>>>> >>>>>>> Also, I think we need to define the "address space" of a process, >>>>>>> and an "image list" as a collection of image files that have been >>>>>>> loaded in the address space, and possibly relocated at runtime. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think I agree with both comments. Image should not refer to a >>>>>>> single executable image (a.out or a.exe), but rather the base >>>>>>> executable and the shared libraries that were loaded into the >>>>>>> process address space. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So how about this new definition: >>>>>>> >>>>>>> An image represents the executable (e.g., a.out) and the collection >>>>>>> of dynamically loaded libraries that were loaded into the process >>>>>>> address space. >>>>>>> >>>>>>> >>>>>>> >>>>>>> --Anh >>>>>>> >>>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> [mailto:[email protected] >>>>>>> <mailto:[email protected]>] *On Behalf Of >>>>>>> *Kathryn Mohror >>>>>>> *Sent:* Tuesday, May 21, 2013 6:27 PM >>>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> >>>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you for the extensive feedback and help with the document! I'm >>>>>>> sure you will get the 'nod' you referred to on page 1 :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> For the definition of mqs_image, I agree that it needs work. Dong >>>>>>> Ahn also mentioned that it needed to be more rigorously defined. >>>>>>> However if possible, I think it would be beneficial if we could at >>>>>>> least start the conversation before next week so that we have a >>>>>>> better chance of having it nailed down in advance of the next meeting. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So, that said -- does anyone want to take a first stab at a >>>>>>> definition to get us started? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kathryn >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 21, 2013, at 2:18 PM, John DelSignore >>>>>>> <John.DelSignore(a)roguewave.com <mailto:[email protected]> >>>>>>> <mailto:[email protected]>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Attached are my edits and comments on the MPI Message Queue >>>>>>> document. Anh provided me with a Word document generated from the >>>>>>> LaTex, so the formatting is funky in some places. I enabled change >>>>>>> tracking in Word before making my edits, and I added many comments >>>>>>> to the document in places where I think we have more work to do. >>>>>>> Unfortunately, I think the changes might be somewhat extensive. >>>>>>> >>>>>>> The volume of edits and comments aside, I think Anh did a great job! >>>>>>> The first draft of the document closely reflects the 10+ year-old >>>>>>> description of the interface pretty well. Unfortunately, the >>>>>>> original interface has some problem that we need to resolve, most >>>>>>> critically, we have to resolve how to describe the concept of >>>>>>> "mqs_image". We can talk about this during the next concall. >>>>>>> >>>>>>> Cheers, John D. >>>>>>> >>>>>>> >>>>>>> Anh Vo wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As mentioned on the tool WG call today, I'm re-sending the >>>>>>> latest draft. >>>>>>> Feedbacks are appreciated. We'll send this one out to the wider >>>>>>> audience >>>>>>> on Tuesday 5/21 to meet the requirement for first reading in >>>>>>> June >>>>>>> >>>>>>> >>>>>>> >>>>>>> --Anh >>>>>>> >>>>>>> <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>>>> <mailto:[email protected]> <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________________________________________ >>>>>>> Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> >>>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> <msgq.pdf>_______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________________________________________ >>>>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-tools mailing list >>>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________________________________________ >>>>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> >>>> _______________________________________________ >>>> Mpi3-tools mailing list >>>> Mpi3-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> -- >>> 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 >>> ALCF docs: http://www.alcf.anl.gov/user-guides >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >

1 0

Re: [Mpi3-tools] latest draft of mqs
by Jeff Hammond 23 May '13

23 May '13

My recollection of the 'worst idea ever' included attempts at using website-based conversion tools such as this one. The MPI documents must be easier to convert due to lack of images and equations, because they didn't help my cause any more than good old fashioned text-based copy-and-paste + redo everything that isn't raw ASCII. Jeff On Thu, May 23, 2013 at 8:30 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Jeff -- > > I think we got trumped by http://www.pdftoword.com/. :-) > > > On May 23, 2013, at 9:11 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > >> In order words, what Squyres is trying to say that the original is >> written in LaTeX, not Word, and thus editing it natively requires >> LaTeX expertise, and not just the usual level, since MPI standard >> documents use lots of voodoo that may or may not have been invented by >> Bill Gropp, who is master of software voodoo* :-) >> >> * e.g. http://www.cs.uiuc.edu/homes/wgropp/projects/software/sowing/index.htm >> >> Having tried once to co-mingle Word and LaTeX authoring (the joys of >> interdisciplinary proposal writing), I can say without any hesitation >> that this is the worst idea ever. I have never hated myself more than >> the weekend I had to merge a LaTeX-generated PDF and a Word document, >> including two distinct and very long bibliographies in their respect >> native formats. >> >> Jeff >> >> On Thu, May 23, 2013 at 7:59 PM, Jeff Squyres (jsquyres) >> <jsquyres(a)cisco.com> wrote: >>> John -- >>> >>> FWIW: what I did to send edits was to print out the PDF, write out my edits, scan in the pages, and send the resulting scan-PDF to Ahn. >>> >>> That might save Ahn a lot of time compared to transcribing the whole document to Word...? >>> >>> >>> >>> On May 23, 2013, at 8:09 PM, John DelSignore <John.DelSignore(a)roguewave.com> >>> wrote: >>> >>>> Hi Anh, >>>> >>>> Could you please send the Word version of the document too? >>>> >>>> Thanks, John D. >>>> >>>> >>>> Anh Vo wrote: >>>>> Hi all, >>>>> I'm done with my edits. Attached is the latest draft. The latex is also checked in. >>>>> >>>>> --Anh >>>>> >>>>> -----Original Message----- >>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo >>>>> Sent: Thursday, May 23, 2013 1:49 PM >>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> Hi John, >>>>> Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. >>>>> >>>>> The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) >>>>> >>>>> --Anh >>>>> >>>>> -----Original Message----- >>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore >>>>> Sent: Thursday, May 23, 2013 12:52 PM >>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. >>>>> >>>>> One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. >>>>> >>>>> Cheers, John D. >>>>> >>>>> >>>>> Anh Vo wrote: >>>>>> Hi all, >>>>>> >>>>>> I have updated the MQS draft incorporating most of John's feedbacks. >>>>>> There are still a few items here and there and I plan to get it done >>>>>> by the end of today so we can send it out to the forum before Friday >>>>>> noon as we promised. >>>>>> >>>>>> I'm sending this now since I need feedbacks on some of the new >>>>>> definitions provided in chapter 3. Please look at Chapter 3. Note that >>>>>> due to our definition of mqs_image, the document will use >>>>>> \emph{mqs_image} in place of image (this is one part that I will go >>>>>> through and make sure I change them). \variable{mqs_image} will be >>>>>> used when referring to the type mqs_image of the interface. >>>>>> >>>>>> >>>>>> >>>>>> --Anh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> [mailto:[email protected]] *On Behalf Of *Kathryn >>>>>> Mohror >>>>>> *Sent:* Wednesday, May 22, 2013 2:16 PM >>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> >>>>>> >>>>>> Comments inline >>>>>> >>>>>> >>>>>> >>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>> <mailto:[email protected]>] *On Behalf Of *Kathryn >>>>>> Mohror >>>>>> *Sent:* Wednesday, May 22, 2013 1:44 PM >>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> >>>>>> >>>>>> Hi Ahn, >>>>>> >>>>>> >>>>>> >>>>>> comments inline: >>>>>> >>>>>> Page 2, Comment JD4 >>>>>> John's comments about lots of hyphenated identifiers at end of line. >>>>>> Some of it are artifacts of converting PDF -> Word, but I think this >>>>>> is a common (and widely accepted) problems of latex documents. So we >>>>>> will probably have to live with it unless there're some magic way to >>>>>> make it nicer. >>>>>> >>>>>> >>>>>> >>>>>> I searched the standard (with PDF viewer search) and didn't see any >>>>>> broken hyphenated identifiers at the ends of lines. I noted that in >>>>>> the standard type and function names are like so: MPI\_COMM\_WORLD >>>>>> while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If >>>>>> you remove the \- will it do the right thing? I am not a Latex guru >>>>>> so I don't know. >>>>>> >>>>>> [anhvo]: Yes, I think I mainly followed the practice of the latex in >>>>>> MPIR and put the \- there, it basically tells Latex it can break off >>>>>> the lines there. Not sure which one is more desirable? >>>>>> >>>>>> >>>>>> >>>>>> I don't care either way really, except I think it looks bad if words >>>>>> go past the end of the margin if LaTeX doesn't know what to do with >>>>>> the word. There's probably some magic to fix that but I don't know it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted >>>>>> table similar to what the MPIR document had. For example: >>>>>> >>>>>> Char MPIR_dll_name[] >>>>>> Definition is required >>>>>> Definition is contained within the address space of the MPI process >>>>>> Variable is written by the MPI process, and read by the tool >>>>>> >>>>>> I thought I did ask about this in the conf call at some point (or >>>>>> maybe it was an email, I can't remember the exact time and place) and >>>>>> we agreed that we would not be using that format because many people >>>>>> in the forum thought it was weird looking. >>>>>> >>>>>> >>>>>> >>>>>> Well, my opinion is that it should be consistent with what is in MPIR >>>>>> since it's supposed to be part of the same document. I don't remember >>>>>> the 'weird looking' comment, but I wouldn't be surprised if someone made it. >>>>>> >>>>>> [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to >>>>>> me. And I agreed with Jeff so I removed it. I might be in the minority >>>>>> but I don't necessarily agree that we should have similar format with >>>>>> the MPIR Document. They're both side documents but they're quite >>>>>> different. In MPIR there are many variables so it's quite important to >>>>>> mention where they should stay and who is writing, reading it. In MQS >>>>>> we separate callbacks by debugger and DLL so it's quite clear who >>>>>> should define what >>>>>> >>>>>> >>>>>> >>>>>> Maybe a compromise is to put this sort of information at the top of >>>>>> each section.subsection that defines a set of variables? You already >>>>>> say it in the text, but pulling it out somehow may be helpful to >>>>>> people new to the interface. It's just an idea... I'm not married to it. >>>>>> >>>>>> >>>>>> >>>>>> Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at >>>>>> the end of the typedef definition? When I first created the document, >>>>>> I also debated a bit between this. I ended up following the style of >>>>>> the MPI standard where it lists the C declaration without any ; I'm >>>>>> fine either way, but would like to hear others' opinions on this. >>>>>> >>>>>> >>>>>> >>>>>> I think the standard does use ; . At least I didn't see any -- did I >>>>>> miss what you mean? >>>>>> >>>>>> [anhvo]: The standard does not put semicolon after a C definition. >>>>>> Randomly picking: page 38, C definition of MPI_BSend: >>>>>> >>>>>> int MPI_Bsend(...) (no semicolon at the end) >>>>>> >>>>>> >>>>>> >>>>>> Oh, yes I see what you mean. Okay, given that I would vote for no ; >>>>>> >>>>>> >>>>>> >>>>>> Kathryn >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your hard work Ahn! >>>>>> >>>>>> Kathryn >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'm leaving for lunch now. More comments after I'm back. In the >>>>>> meantime, if folks can comments on what I've sent so far, that'd be >>>>>> great!! >>>>>> >>>>>> Thanks >>>>>> Anh >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>> <mailto:[email protected]>] On Behalf Of Anh Vo >>>>>> Sent: Wednesday, May 22, 2013 8:10 AM >>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> The definitions John provide look great for me. Unless there are >>>>>> other opinions, I will use those. >>>>>> >>>>>> --Anh >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> [mailto:[email protected] >>>>>> <mailto:[email protected]>] On Behalf Of Ahn, Dong H. >>>>>> Sent: Wednesday, May 22, 2013 7:54 AM >>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> Hi John, >>>>>> >>>>>> This works for me and should clarify a few things in the current draft. >>>>>> >>>>>> Best, >>>>>> Dong >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> [mailto:[email protected] >>>>>> <mailto:[email protected]>] On Behalf Of John >>>>>> DelSignore >>>>>> Sent: Wednesday, May 22, 2013 9:55 AM >>>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> I prefer to not muddy up the "standard definitions" (or maybe >>>>>> "common-sense definitions") of commonly used term, such as "image >>>>>> file", to make them conform to the MQD interface. Instead, I like to >>>>>> define the MQD typedefs in terms of the standard definitions. So, >>>>>> WRT to the document, I think we should include the following >>>>>> definitions: >>>>>> >>>>>> * An "image file" is an executable or shared library file, that may >>>>>> contain symbol definitions needed by the MQD interface. >>>>>> >>>>>> * An "MPI process" consists of an "address space" and a collection >>>>>> of execution contexts (threads or lightweight processes). >>>>>> >>>>>> * An "address space" is a region of memory that consists of executable >>>>>> code and data, and is partially composed of a collection of image >>>>>> files. The collection of image files may change at any point during >>>>>> the execution of the MPI process, and image files may be relocated >>>>>> at runtime within the address space at the point they are loaded >>>>>> into memory. >>>>>> >>>>>> Then we can say: >>>>>> >>>>>> * An "mqs_image" is an abstract concept that represents the collection >>>>>> of image files loaded into the address space of the MPI process at any >>>>>> given time, and is debugger implementation defined. In static >>>>>> execution environments, where shared libraries are not supported, an >>>>>> mqs_image can represent an executable image file. However, in dynamic >>>>>> execution environments, where shared libraries, dynamically loaded >>>>>> shared libraries, and runtime relocation of shared libraries are >>>>>> supported, an mqs_image should represent the collection of image >>>>>> files loaded into the address space of the MPI process at any given >>>>>> point in time; in this situation, mqs_image may in fact represent >>>>>> the MPI process itself. >>>>>> >>>>>> Cheers, John D. >>>>>> >>>>>> >>>>>> Anh Vo wrote: >>>>>> >>>>>> >>>>>> Thanks Kathryn for starting up the discussion. >>>>>> >>>>>> >>>>>> >>>>>> I'll start with my existing definition of mqs_image in the document, >>>>>> which definitely is not adequate. >>>>>> >>>>>> >>>>>> >>>>>> Existing definition: >>>>>> >>>>>> An image is an executable file that was loaded into memory when >>>>>> >>>>>> a process is started. For SIMD-style programs, all MPI processes >>>>>> have >>>>>> >>>>>> the same image. For MIMD-style programs, MPI processes might have >>>>>> >>>>>> different images. >>>>>> >>>>>> >>>>>> >>>>>> Dong's comments: >>>>>> >>>>>> The definition of "Image" isn't all that rigorous here. I think this >>>>>> creates some confusion somewhere down this document. Is an image >>>>>> really an executable file? Which typically means the base >>>>>> executable or does this refer to both the based executable and DSOs >>>>>> being loaded into the process address space? Though it sounds >>>>>> hair-splitting, even the SPMD remark, the statement is only true if >>>>>> the image is defined to be the base executable. >>>>>> >>>>>> >>>>>> >>>>>> John's comments: >>>>>> >>>>>> I think we should be more general with the term "image" to mean >>>>>> executable or shared library. The reason is that we do not want to >>>>>> require symbols to reside in the executable. We should allow symbols >>>>>> to reside in shared libraries. >>>>>> >>>>>> Also, I think we need to define the "address space" of a process, >>>>>> and an "image list" as a collection of image files that have been >>>>>> loaded in the address space, and possibly relocated at runtime. >>>>>> >>>>>> >>>>>> >>>>>> I think I agree with both comments. Image should not refer to a >>>>>> single executable image (a.out or a.exe), but rather the base >>>>>> executable and the shared libraries that were loaded into the >>>>>> process address space. >>>>>> >>>>>> >>>>>> >>>>>> So how about this new definition: >>>>>> >>>>>> An image represents the executable (e.g., a.out) and the collection >>>>>> of dynamically loaded libraries that were loaded into the process >>>>>> address space. >>>>>> >>>>>> >>>>>> >>>>>> --Anh >>>>>> >>>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> [mailto:[email protected] >>>>>> <mailto:[email protected]>] *On Behalf Of >>>>>> *Kathryn Mohror >>>>>> *Sent:* Tuesday, May 21, 2013 6:27 PM >>>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> >>>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>>> >>>>>> >>>>>> >>>>>> Hi John, >>>>>> >>>>>> >>>>>> >>>>>> Thank you for the extensive feedback and help with the document! I'm >>>>>> sure you will get the 'nod' you referred to on page 1 :-) >>>>>> >>>>>> >>>>>> >>>>>> For the definition of mqs_image, I agree that it needs work. Dong >>>>>> Ahn also mentioned that it needed to be more rigorously defined. >>>>>> However if possible, I think it would be beneficial if we could at >>>>>> least start the conversation before next week so that we have a >>>>>> better chance of having it nailed down in advance of the next meeting. >>>>>> >>>>>> >>>>>> >>>>>> So, that said -- does anyone want to take a first stab at a >>>>>> definition to get us started? >>>>>> >>>>>> >>>>>> >>>>>> Kathryn >>>>>> >>>>>> >>>>>> >>>>>> On May 21, 2013, at 2:18 PM, John DelSignore >>>>>> <John.DelSignore(a)roguewave.com <mailto:[email protected]> >>>>>> <mailto:[email protected]>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Attached are my edits and comments on the MPI Message Queue >>>>>> document. Anh provided me with a Word document generated from the >>>>>> LaTex, so the formatting is funky in some places. I enabled change >>>>>> tracking in Word before making my edits, and I added many comments >>>>>> to the document in places where I think we have more work to do. >>>>>> Unfortunately, I think the changes might be somewhat extensive. >>>>>> >>>>>> The volume of edits and comments aside, I think Anh did a great job! >>>>>> The first draft of the document closely reflects the 10+ year-old >>>>>> description of the interface pretty well. Unfortunately, the >>>>>> original interface has some problem that we need to resolve, most >>>>>> critically, we have to resolve how to describe the concept of >>>>>> "mqs_image". We can talk about this during the next concall. >>>>>> >>>>>> Cheers, John D. >>>>>> >>>>>> >>>>>> Anh Vo wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> As mentioned on the tool WG call today, I'm re-sending the >>>>>> latest draft. >>>>>> Feedbacks are appreciated. We'll send this one out to the wider >>>>>> audience >>>>>> on Tuesday 5/21 to meet the requirement for first reading in >>>>>> June >>>>>> >>>>>> >>>>>> >>>>>> --Anh >>>>>> >>>>>> <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>>> <mailto:[email protected]> <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> >>>>>> ______________________________________________________________ >>>>>> Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> >>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> <msgq.pdf>_______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> >>>>>> ______________________________________________________________ >>>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-tools mailing list >>>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>>> >>>>>> >>>>>> >>>>>> ______________________________________________________________ >>>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Mpi3-tools mailing list >>>> Mpi3-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> -- >> 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 >> ALCF docs: http://www.alcf.anl.gov/user-guides >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [Mpi3-tools] latest draft of mqs
by Jeff Squyres (jsquyres) 23 May '13

23 May '13

Jeff -- I think we got trumped by http://www.pdftoword.com/. :-) On May 23, 2013, at 9:11 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > In order words, what Squyres is trying to say that the original is > written in LaTeX, not Word, and thus editing it natively requires > LaTeX expertise, and not just the usual level, since MPI standard > documents use lots of voodoo that may or may not have been invented by > Bill Gropp, who is master of software voodoo* :-) > > * e.g. http://www.cs.uiuc.edu/homes/wgropp/projects/software/sowing/index.htm > > Having tried once to co-mingle Word and LaTeX authoring (the joys of > interdisciplinary proposal writing), I can say without any hesitation > that this is the worst idea ever. I have never hated myself more than > the weekend I had to merge a LaTeX-generated PDF and a Word document, > including two distinct and very long bibliographies in their respect > native formats. > > Jeff > > On Thu, May 23, 2013 at 7:59 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com> wrote: >> John -- >> >> FWIW: what I did to send edits was to print out the PDF, write out my edits, scan in the pages, and send the resulting scan-PDF to Ahn. >> >> That might save Ahn a lot of time compared to transcribing the whole document to Word...? >> >> >> >> On May 23, 2013, at 8:09 PM, John DelSignore <John.DelSignore(a)roguewave.com> >> wrote: >> >>> Hi Anh, >>> >>> Could you please send the Word version of the document too? >>> >>> Thanks, John D. >>> >>> >>> Anh Vo wrote: >>>> Hi all, >>>> I'm done with my edits. Attached is the latest draft. The latex is also checked in. >>>> >>>> --Anh >>>> >>>> -----Original Message----- >>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Anh Vo >>>> Sent: Thursday, May 23, 2013 1:49 PM >>>> To: mpi3-tools(a)lists.mpi-forum.org >>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>> >>>> Hi John, >>>> Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. >>>> >>>> The searching issue is probably reader dependent. I do not have issue finding the instance on Step 9 on page 7 using Foxit Reader (see attached screenshot). I do not use Adobe Reader so I can't tell whether it would experience the issue you mentioned. If we don't break off the hyphenation, Latex will not know what to do with it and will simply overflow the text on that line, which makes it look quite bad (see attached screenshot) >>>> >>>> --Anh >>>> >>>> -----Original Message----- >>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore >>>> Sent: Thursday, May 23, 2013 12:52 PM >>>> To: mpi3-tools(a)lists.mpi-forum.org >>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>> >>>> Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. >>>> >>>> One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. >>>> >>>> Cheers, John D. >>>> >>>> >>>> Anh Vo wrote: >>>>> Hi all, >>>>> >>>>> I have updated the MQS draft incorporating most of John's feedbacks. >>>>> There are still a few items here and there and I plan to get it done >>>>> by the end of today so we can send it out to the forum before Friday >>>>> noon as we promised. >>>>> >>>>> I'm sending this now since I need feedbacks on some of the new >>>>> definitions provided in chapter 3. Please look at Chapter 3. Note that >>>>> due to our definition of mqs_image, the document will use >>>>> \emph{mqs_image} in place of image (this is one part that I will go >>>>> through and make sure I change them). \variable{mqs_image} will be >>>>> used when referring to the type mqs_image of the interface. >>>>> >>>>> >>>>> >>>>> --Anh >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> [mailto:[email protected]] *On Behalf Of *Kathryn >>>>> Mohror >>>>> *Sent:* Wednesday, May 22, 2013 2:16 PM >>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> >>>>> >>>>> Comments inline >>>>> >>>>> >>>>> >>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> [mailto:[email protected] >>>>> <mailto:[email protected]>] *On Behalf Of *Kathryn >>>>> Mohror >>>>> *Sent:* Wednesday, May 22, 2013 1:44 PM >>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> >>>>> >>>>> Hi Ahn, >>>>> >>>>> >>>>> >>>>> comments inline: >>>>> >>>>> Page 2, Comment JD4 >>>>> John's comments about lots of hyphenated identifiers at end of line. >>>>> Some of it are artifacts of converting PDF -> Word, but I think this >>>>> is a common (and widely accepted) problems of latex documents. So we >>>>> will probably have to live with it unless there're some magic way to >>>>> make it nicer. >>>>> >>>>> >>>>> >>>>> I searched the standard (with PDF viewer search) and didn't see any >>>>> broken hyphenated identifiers at the ends of lines. I noted that in >>>>> the standard type and function names are like so: MPI\_COMM\_WORLD >>>>> while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If >>>>> you remove the \- will it do the right thing? I am not a Latex guru >>>>> so I don't know. >>>>> >>>>> [anhvo]: Yes, I think I mainly followed the practice of the latex in >>>>> MPIR and put the \- there, it basically tells Latex it can break off >>>>> the lines there. Not sure which one is more desirable? >>>>> >>>>> >>>>> >>>>> I don't care either way really, except I think it looks bad if words >>>>> go past the end of the margin if LaTeX doesn't know what to do with >>>>> the word. There's probably some magic to fix that but I don't know it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Page 9 (Page 14 in Word), Comment JD18 John recommended the formatted >>>>> table similar to what the MPIR document had. For example: >>>>> >>>>> Char MPIR_dll_name[] >>>>> Definition is required >>>>> Definition is contained within the address space of the MPI process >>>>> Variable is written by the MPI process, and read by the tool >>>>> >>>>> I thought I did ask about this in the conf call at some point (or >>>>> maybe it was an email, I can't remember the exact time and place) and >>>>> we agreed that we would not be using that format because many people >>>>> in the forum thought it was weird looking. >>>>> >>>>> >>>>> >>>>> Well, my opinion is that it should be consistent with what is in MPIR >>>>> since it's supposed to be part of the same document. I don't remember >>>>> the 'weird looking' comment, but I wouldn't be surprised if someone made it. >>>>> >>>>> [anhvo] I think Jeff mentioned this in the scanned PDF he sent back to >>>>> me. And I agreed with Jeff so I removed it. I might be in the minority >>>>> but I don't necessarily agree that we should have similar format with >>>>> the MPIR Document. They're both side documents but they're quite >>>>> different. In MPIR there are many variables so it's quite important to >>>>> mention where they should stay and who is writing, reading it. In MQS >>>>> we separate callbacks by debugger and DLL so it's quite clear who >>>>> should define what >>>>> >>>>> >>>>> >>>>> Maybe a compromise is to put this sort of information at the top of >>>>> each section.subsection that defines a set of variables? You already >>>>> say it in the text, but pulling it out somehow may be helpful to >>>>> people new to the interface. It's just an idea... I'm not married to it. >>>>> >>>>> >>>>> >>>>> Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon at >>>>> the end of the typedef definition? When I first created the document, >>>>> I also debated a bit between this. I ended up following the style of >>>>> the MPI standard where it lists the C declaration without any ; I'm >>>>> fine either way, but would like to hear others' opinions on this. >>>>> >>>>> >>>>> >>>>> I think the standard does use ; . At least I didn't see any -- did I >>>>> miss what you mean? >>>>> >>>>> [anhvo]: The standard does not put semicolon after a C definition. >>>>> Randomly picking: page 38, C definition of MPI_BSend: >>>>> >>>>> int MPI_Bsend(...) (no semicolon at the end) >>>>> >>>>> >>>>> >>>>> Oh, yes I see what you mean. Okay, given that I would vote for no ; >>>>> >>>>> >>>>> >>>>> Kathryn >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks for your hard work Ahn! >>>>> >>>>> Kathryn >>>>> >>>>> >>>>> >>>>> >>>>> I'm leaving for lunch now. More comments after I'm back. In the >>>>> meantime, if folks can comments on what I've sent so far, that'd be >>>>> great!! >>>>> >>>>> Thanks >>>>> Anh >>>>> >>>>> -----Original Message----- >>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> [mailto:[email protected] >>>>> <mailto:[email protected]>] On Behalf Of Anh Vo >>>>> Sent: Wednesday, May 22, 2013 8:10 AM >>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> The definitions John provide look great for me. Unless there are >>>>> other opinions, I will use those. >>>>> >>>>> --Anh >>>>> >>>>> -----Original Message----- >>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> [mailto:[email protected] >>>>> <mailto:[email protected]>] On Behalf Of Ahn, Dong H. >>>>> Sent: Wednesday, May 22, 2013 7:54 AM >>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> Hi John, >>>>> >>>>> This works for me and should clarify a few things in the current draft. >>>>> >>>>> Best, >>>>> Dong >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> [mailto:[email protected] >>>>> <mailto:[email protected]>] On Behalf Of John >>>>> DelSignore >>>>> Sent: Wednesday, May 22, 2013 9:55 AM >>>>> To: mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> Subject: Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> I prefer to not muddy up the "standard definitions" (or maybe >>>>> "common-sense definitions") of commonly used term, such as "image >>>>> file", to make them conform to the MQD interface. Instead, I like to >>>>> define the MQD typedefs in terms of the standard definitions. So, >>>>> WRT to the document, I think we should include the following >>>>> definitions: >>>>> >>>>> * An "image file" is an executable or shared library file, that may >>>>> contain symbol definitions needed by the MQD interface. >>>>> >>>>> * An "MPI process" consists of an "address space" and a collection >>>>> of execution contexts (threads or lightweight processes). >>>>> >>>>> * An "address space" is a region of memory that consists of executable >>>>> code and data, and is partially composed of a collection of image >>>>> files. The collection of image files may change at any point during >>>>> the execution of the MPI process, and image files may be relocated >>>>> at runtime within the address space at the point they are loaded >>>>> into memory. >>>>> >>>>> Then we can say: >>>>> >>>>> * An "mqs_image" is an abstract concept that represents the collection >>>>> of image files loaded into the address space of the MPI process at any >>>>> given time, and is debugger implementation defined. In static >>>>> execution environments, where shared libraries are not supported, an >>>>> mqs_image can represent an executable image file. However, in dynamic >>>>> execution environments, where shared libraries, dynamically loaded >>>>> shared libraries, and runtime relocation of shared libraries are >>>>> supported, an mqs_image should represent the collection of image >>>>> files loaded into the address space of the MPI process at any given >>>>> point in time; in this situation, mqs_image may in fact represent >>>>> the MPI process itself. >>>>> >>>>> Cheers, John D. >>>>> >>>>> >>>>> Anh Vo wrote: >>>>> >>>>> >>>>> Thanks Kathryn for starting up the discussion. >>>>> >>>>> >>>>> >>>>> I'll start with my existing definition of mqs_image in the document, >>>>> which definitely is not adequate. >>>>> >>>>> >>>>> >>>>> Existing definition: >>>>> >>>>> An image is an executable file that was loaded into memory when >>>>> >>>>> a process is started. For SIMD-style programs, all MPI processes >>>>> have >>>>> >>>>> the same image. For MIMD-style programs, MPI processes might have >>>>> >>>>> different images. >>>>> >>>>> >>>>> >>>>> Dong's comments: >>>>> >>>>> The definition of "Image" isn't all that rigorous here. I think this >>>>> creates some confusion somewhere down this document. Is an image >>>>> really an executable file? Which typically means the base >>>>> executable or does this refer to both the based executable and DSOs >>>>> being loaded into the process address space? Though it sounds >>>>> hair-splitting, even the SPMD remark, the statement is only true if >>>>> the image is defined to be the base executable. >>>>> >>>>> >>>>> >>>>> John's comments: >>>>> >>>>> I think we should be more general with the term "image" to mean >>>>> executable or shared library. The reason is that we do not want to >>>>> require symbols to reside in the executable. We should allow symbols >>>>> to reside in shared libraries. >>>>> >>>>> Also, I think we need to define the "address space" of a process, >>>>> and an "image list" as a collection of image files that have been >>>>> loaded in the address space, and possibly relocated at runtime. >>>>> >>>>> >>>>> >>>>> I think I agree with both comments. Image should not refer to a >>>>> single executable image (a.out or a.exe), but rather the base >>>>> executable and the shared libraries that were loaded into the >>>>> process address space. >>>>> >>>>> >>>>> >>>>> So how about this new definition: >>>>> >>>>> An image represents the executable (e.g., a.out) and the collection >>>>> of dynamically loaded libraries that were loaded into the process >>>>> address space. >>>>> >>>>> >>>>> >>>>> --Anh >>>>> >>>>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> [mailto:[email protected] >>>>> <mailto:[email protected]>] *On Behalf Of >>>>> *Kathryn Mohror >>>>> *Sent:* Tuesday, May 21, 2013 6:27 PM >>>>> *To:* mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> >>>>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>>>> >>>>> >>>>> >>>>> Hi John, >>>>> >>>>> >>>>> >>>>> Thank you for the extensive feedback and help with the document! I'm >>>>> sure you will get the 'nod' you referred to on page 1 :-) >>>>> >>>>> >>>>> >>>>> For the definition of mqs_image, I agree that it needs work. Dong >>>>> Ahn also mentioned that it needed to be more rigorously defined. >>>>> However if possible, I think it would be beneficial if we could at >>>>> least start the conversation before next week so that we have a >>>>> better chance of having it nailed down in advance of the next meeting. >>>>> >>>>> >>>>> >>>>> So, that said -- does anyone want to take a first stab at a >>>>> definition to get us started? >>>>> >>>>> >>>>> >>>>> Kathryn >>>>> >>>>> >>>>> >>>>> On May 21, 2013, at 2:18 PM, John DelSignore >>>>> <John.DelSignore(a)roguewave.com <mailto:[email protected]> >>>>> <mailto:[email protected]>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Attached are my edits and comments on the MPI Message Queue >>>>> document. Anh provided me with a Word document generated from the >>>>> LaTex, so the formatting is funky in some places. I enabled change >>>>> tracking in Word before making my edits, and I added many comments >>>>> to the document in places where I think we have more work to do. >>>>> Unfortunately, I think the changes might be somewhat extensive. >>>>> >>>>> The volume of edits and comments aside, I think Anh did a great job! >>>>> The first draft of the document closely reflects the 10+ year-old >>>>> description of the interface pretty well. Unfortunately, the >>>>> original interface has some problem that we need to resolve, most >>>>> critically, we have to resolve how to describe the concept of >>>>> "mqs_image". We can talk about this during the next concall. >>>>> >>>>> Cheers, John D. >>>>> >>>>> >>>>> Anh Vo wrote: >>>>> >>>>> Hi all, >>>>> >>>>> As mentioned on the tool WG call today, I'm re-sending the >>>>> latest draft. >>>>> Feedbacks are appreciated. We'll send this one out to the wider >>>>> audience >>>>> on Tuesday 5/21 to meet the requirement for first reading in >>>>> June >>>>> >>>>> >>>>> >>>>> --Anh >>>>> >>>>> <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org >>>>> <mailto:[email protected]> <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> >>>>> ______________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> >>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> <msgq.pdf>_______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> >>>>> ______________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mpi3-tools mailing list >>>>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>>> >>>>> >>>>> >>>>> ______________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>>>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Mpi3-tools mailing list >>>> Mpi3-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>> >>>> >>>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-tools] latest draft of mqs
by Anh Vo 23 May '13

23 May '13

Actually I used an online service to convert pdf to word and I think it's doing a decent job at converting http://www.pdftoword.com/ Since whatever we're doing is not top secret, it's probably okay to use it :-) --Anh -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) Sent: Thursday, May 23, 2013 6:00 PM To: <mpi3-tools(a)lists.mpi-forum.org> Subject: Re: [Mpi3-tools] latest draft of mqs John -- FWIW: what I did to send edits was to print out the PDF, write out my edits, scan in the pages, and send the resulting scan-PDF to Ahn. That might save Ahn a lot of time compared to transcribing the whole document to Word...? On May 23, 2013, at 8:09 PM, John DelSignore <John.DelSignore(a)roguewave.com> wrote: > Hi Anh, > > Could you please send the Word version of the document too? > > Thanks, John D. > > > Anh Vo wrote: >> Hi all, >> I'm done with my edits. Attached is the latest draft. The latex is also checked in. >> >> --Anh >> >> -----Original Message----- >> From: mpi3-tools-bounces(a)lists.mpi-forum.org >> [mailto:[email protected]] On Behalf Of Anh Vo >> Sent: Thursday, May 23, 2013 1:49 PM >> To: mpi3-tools(a)lists.mpi-forum.org >> Subject: Re: [Mpi3-tools] latest draft of mqs >> >> Hi John, >> Thanks for looking at the PDF. My purpose of sending the last iteration out is to get feedbacks on the definitions section, because it is quite important to agree on the terms that will be using for the rest of the documents. If I wait until I finish all my edits to send out and people do not agree on the terms, I have to go back and make a lot of edits and send out another PDF, so on and so forth, which would drag the process out a lot longer. Hopefully this is okay. And I would say that all the important edits are already there, the only thing left is to agree on the usage of mqs_image vs image and I'll go and make all the relevant edits. >> >> The searching issue is probably reader dependent. I do not have issue >> finding the instance on Step 9 on page 7 using Foxit Reader (see >> attached screenshot). I do not use Adobe Reader so I can't tell >> whether it would experience the issue you mentioned. If we don't >> break off the hyphenation, Latex will not know what to do with it and >> will simply overflow the text on that line, which makes it look quite >> bad (see attached screenshot) >> >> --Anh >> >> -----Original Message----- >> From: mpi3-tools-bounces(a)lists.mpi-forum.org >> [mailto:[email protected]] On Behalf Of John >> DelSignore >> Sent: Thursday, May 23, 2013 12:52 PM >> To: mpi3-tools(a)lists.mpi-forum.org >> Subject: Re: [Mpi3-tools] latest draft of mqs >> >> Thanks Anh, I'll take a look at it, though I don't really want to do another meticulous review until you are completely done with your edits. >> >> One comment on the hyphenation issue... I think we should not allow identifiers in the interface to be hyphenated because it means that I cannot search for the identifier as a token. For example, do a text find in your PDF reader (Acrobat or whatever) for mqs_update_communicator_list in the PDF document. In my PDF readers, it does not find the occurrence of that identifier in step 9 on page 7. Part of the usefulness of these documents is that you can search them looking for identifier names. When they are hyphenated, that breaks that capability. I don't care as much if certain words used in the prose is hyphenated, as long as the words that someone might be inclined to search for in the document are not hyphenated. In a document like this, I can image that someone might want to search for words like "breakpoint", "communicator", "iterate", etc. >> >> Cheers, John D. >> >> >> Anh Vo wrote: >>> Hi all, >>> >>> I have updated the MQS draft incorporating most of John's feedbacks. >>> There are still a few items here and there and I plan to get it done >>> by the end of today so we can send it out to the forum before Friday >>> noon as we promised. >>> >>> I'm sending this now since I need feedbacks on some of the new >>> definitions provided in chapter 3. Please look at Chapter 3. Note >>> that due to our definition of mqs_image, the document will use >>> \emph{mqs_image} in place of image (this is one part that I will go >>> through and make sure I change them). \variable{mqs_image} will be >>> used when referring to the type mqs_image of the interface. >>> >>> >>> >>> --Anh >>> >>> >>> >>> >>> >>> >>> >>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>> [mailto:[email protected]] *On Behalf Of >>> *Kathryn Mohror >>> *Sent:* Wednesday, May 22, 2013 2:16 PM >>> *To:* mpi3-tools(a)lists.mpi-forum.org >>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>> >>> >>> >>> Comments inline >>> >>> >>> >>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>> <mailto:[email protected]> [mailto:[email protected] >>> <mailto:[email protected]>] *On Behalf Of *Kathryn >>> Mohror >>> *Sent:* Wednesday, May 22, 2013 1:44 PM >>> *To:* mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>> >>> >>> >>> Hi Ahn, >>> >>> >>> >>> comments inline: >>> >>> Page 2, Comment JD4 >>> John's comments about lots of hyphenated identifiers at end of line. >>> Some of it are artifacts of converting PDF -> Word, but I think this >>> is a common (and widely accepted) problems of latex documents. So we >>> will probably have to live with it unless there're some magic way to >>> make it nicer. >>> >>> >>> >>> I searched the standard (with PDF viewer search) and didn't see any >>> broken hyphenated identifiers at the ends of lines. I noted that in >>> the standard type and function names are like so: MPI\_COMM\_WORLD >>> while in MPIR and MQS they are like so: MPI\_\-COMM\_\-WORLD. If >>> you remove the \- will it do the right thing? I am not a Latex guru >>> so I don't know. >>> >>> [anhvo]: Yes, I think I mainly followed the practice of the latex in >>> MPIR and put the \- there, it basically tells Latex it can break off >>> the lines there. Not sure which one is more desirable? >>> >>> >>> >>> I don't care either way really, except I think it looks bad if words >>> go past the end of the margin if LaTeX doesn't know what to do with >>> the word. There's probably some magic to fix that but I don't know it. >>> >>> >>> >>> >>> >>> Page 9 (Page 14 in Word), Comment JD18 John recommended the >>> formatted table similar to what the MPIR document had. For example: >>> >>> Char MPIR_dll_name[] >>> Definition is required >>> Definition is contained within the address space of the MPI process >>> Variable is written by the MPI process, and read by the tool >>> >>> I thought I did ask about this in the conf call at some point (or >>> maybe it was an email, I can't remember the exact time and place) >>> and we agreed that we would not be using that format because many >>> people in the forum thought it was weird looking. >>> >>> >>> >>> Well, my opinion is that it should be consistent with what is in >>> MPIR since it's supposed to be part of the same document. I don't >>> remember the 'weird looking' comment, but I wouldn't be surprised if someone made it. >>> >>> [anhvo] I think Jeff mentioned this in the scanned PDF he sent back >>> to me. And I agreed with Jeff so I removed it. I might be in the >>> minority but I don't necessarily agree that we should have similar >>> format with the MPIR Document. They're both side documents but >>> they're quite different. In MPIR there are many variables so it's >>> quite important to mention where they should stay and who is >>> writing, reading it. In MQS we separate callbacks by debugger and >>> DLL so it's quite clear who should define what >>> >>> >>> >>> Maybe a compromise is to put this sort of information at the top of >>> each section.subsection that defines a set of variables? You already >>> say it in the text, but pulling it out somehow may be helpful to >>> people new to the interface. It's just an idea... I'm not married to it. >>> >>> >>> >>> Page 15 (Page 21 in Word),Comment JD26 Should we include semicolon >>> at the end of the typedef definition? When I first created the >>> document, I also debated a bit between this. I ended up following >>> the style of the MPI standard where it lists the C declaration >>> without any ; I'm fine either way, but would like to hear others' opinions on this. >>> >>> >>> >>> I think the standard does use ; . At least I didn't see any -- did I >>> miss what you mean? >>> >>> [anhvo]: The standard does not put semicolon after a C definition. >>> Randomly picking: page 38, C definition of MPI_BSend: >>> >>> int MPI_Bsend(...) (no semicolon at the end) >>> >>> >>> >>> Oh, yes I see what you mean. Okay, given that I would vote for no ; >>> >>> >>> >>> Kathryn >>> >>> >>> >>> >>> >>> Thanks for your hard work Ahn! >>> >>> Kathryn >>> >>> >>> >>> >>> I'm leaving for lunch now. More comments after I'm back. In the >>> meantime, if folks can comments on what I've sent so far, that'd be >>> great!! >>> >>> Thanks >>> Anh >>> >>> -----Original Message----- >>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>> <mailto:[email protected]> [mailto:[email protected] >>> <mailto:[email protected]>] On Behalf Of Anh Vo >>> Sent: Wednesday, May 22, 2013 8:10 AM >>> To: mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> Subject: Re: [Mpi3-tools] latest draft of mqs >>> >>> The definitions John provide look great for me. Unless there are >>> other opinions, I will use those. >>> >>> --Anh >>> >>> -----Original Message----- >>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>> <mailto:[email protected]> [mailto:[email protected] >>> <mailto:[email protected]>] On Behalf Of Ahn, Dong H. >>> Sent: Wednesday, May 22, 2013 7:54 AM >>> To: mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> Subject: Re: [Mpi3-tools] latest draft of mqs >>> >>> Hi John, >>> >>> This works for me and should clarify a few things in the current draft. >>> >>> Best, >>> Dong >>> >>> >>> >>> -----Original Message----- >>> From: mpi3-tools-bounces(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> [mailto:[email protected] >>> <mailto:[email protected]>] On Behalf Of John >>> DelSignore >>> Sent: Wednesday, May 22, 2013 9:55 AM >>> To: mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> Subject: Re: [Mpi3-tools] latest draft of mqs >>> >>> I prefer to not muddy up the "standard definitions" (or maybe >>> "common-sense definitions") of commonly used term, such as "image >>> file", to make them conform to the MQD interface. Instead, I like to >>> define the MQD typedefs in terms of the standard definitions. So, >>> WRT to the document, I think we should include the following >>> definitions: >>> >>> * An "image file" is an executable or shared library file, that may >>> contain symbol definitions needed by the MQD interface. >>> >>> * An "MPI process" consists of an "address space" and a collection >>> of execution contexts (threads or lightweight processes). >>> >>> * An "address space" is a region of memory that consists of executable >>> code and data, and is partially composed of a collection of image >>> files. The collection of image files may change at any point during >>> the execution of the MPI process, and image files may be relocated >>> at runtime within the address space at the point they are loaded >>> into memory. >>> >>> Then we can say: >>> >>> * An "mqs_image" is an abstract concept that represents the collection >>> of image files loaded into the address space of the MPI process at any >>> given time, and is debugger implementation defined. In static >>> execution environments, where shared libraries are not supported, an >>> mqs_image can represent an executable image file. However, in dynamic >>> execution environments, where shared libraries, dynamically loaded >>> shared libraries, and runtime relocation of shared libraries are >>> supported, an mqs_image should represent the collection of image >>> files loaded into the address space of the MPI process at any given >>> point in time; in this situation, mqs_image may in fact represent >>> the MPI process itself. >>> >>> Cheers, John D. >>> >>> >>> Anh Vo wrote: >>> >>> >>> Thanks Kathryn for starting up the discussion. >>> >>> >>> >>> I'll start with my existing definition of mqs_image in the document, >>> which definitely is not adequate. >>> >>> >>> >>> Existing definition: >>> >>> An image is an executable file that was loaded into memory when >>> >>> a process is started. For SIMD-style programs, all MPI processes >>> have >>> >>> the same image. For MIMD-style programs, MPI processes might have >>> >>> different images. >>> >>> >>> >>> Dong's comments: >>> >>> The definition of "Image" isn't all that rigorous here. I think this >>> creates some confusion somewhere down this document. Is an image >>> really an executable file? Which typically means the base >>> executable or does this refer to both the based executable and DSOs >>> being loaded into the process address space? Though it sounds >>> hair-splitting, even the SPMD remark, the statement is only true if >>> the image is defined to be the base executable. >>> >>> >>> >>> John's comments: >>> >>> I think we should be more general with the term "image" to mean >>> executable or shared library. The reason is that we do not want to >>> require symbols to reside in the executable. We should allow symbols >>> to reside in shared libraries. >>> >>> Also, I think we need to define the "address space" of a process, >>> and an "image list" as a collection of image files that have been >>> loaded in the address space, and possibly relocated at runtime. >>> >>> >>> >>> I think I agree with both comments. Image should not refer to a >>> single executable image (a.out or a.exe), but rather the base >>> executable and the shared libraries that were loaded into the >>> process address space. >>> >>> >>> >>> So how about this new definition: >>> >>> An image represents the executable (e.g., a.out) and the collection >>> of dynamically loaded libraries that were loaded into the process >>> address space. >>> >>> >>> >>> --Anh >>> >>> *From:* mpi3-tools-bounces(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> [mailto:[email protected] >>> <mailto:[email protected]>] *On Behalf Of >>> *Kathryn Mohror >>> *Sent:* Tuesday, May 21, 2013 6:27 PM >>> *To:* mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> *Subject:* Re: [Mpi3-tools] latest draft of mqs >>> >>> >>> >>> Hi John, >>> >>> >>> >>> Thank you for the extensive feedback and help with the document! I'm >>> sure you will get the 'nod' you referred to on page 1 :-) >>> >>> >>> >>> For the definition of mqs_image, I agree that it needs work. Dong >>> Ahn also mentioned that it needed to be more rigorously defined. >>> However if possible, I think it would be beneficial if we could at >>> least start the conversation before next week so that we have a >>> better chance of having it nailed down in advance of the next meeting. >>> >>> >>> >>> So, that said -- does anyone want to take a first stab at a >>> definition to get us started? >>> >>> >>> >>> Kathryn >>> >>> >>> >>> On May 21, 2013, at 2:18 PM, John DelSignore >>> <John.DelSignore(a)roguewave.com <mailto:[email protected]> >>> <mailto:[email protected]>> >>> wrote: >>> >>> >>> >>> Hi, >>> >>> Attached are my edits and comments on the MPI Message Queue >>> document. Anh provided me with a Word document generated from the >>> LaTex, so the formatting is funky in some places. I enabled change >>> tracking in Word before making my edits, and I added many comments >>> to the document in places where I think we have more work to do. >>> Unfortunately, I think the changes might be somewhat extensive. >>> >>> The volume of edits and comments aside, I think Anh did a great job! >>> The first draft of the document closely reflects the 10+ year-old >>> description of the interface pretty well. Unfortunately, the >>> original interface has some problem that we need to resolve, most >>> critically, we have to resolve how to describe the concept of >>> "mqs_image". We can talk about this during the next concall. >>> >>> Cheers, John D. >>> >>> >>> Anh Vo wrote: >>> >>> Hi all, >>> >>> As mentioned on the tool WG call today, I'm re-sending the >>> latest draft. >>> Feedbacks are appreciated. We'll send this one out to the wider >>> audience >>> on Tuesday 5/21 to meet the requirement for first reading in >>> June >>> >>> >>> >>> --Anh >>> >>> <MPI-MQD-JVD-2013-05-17.doc>_______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> >>> ______________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]> >>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> <msgq.pdf>_______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> >>> ______________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov >>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>> >>> >>> >>> ______________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov >>> <mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ >>> Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0