[Mpi3-tools] latest draft of mqs
Anh Vo
Anh.Vo at microsoft.com
Thu May 23 14:32:24 CDT 2013
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 at lists.mpi-forum.org [mailto:mpi3-tools-bounces at lists.mpi-forum.org] On Behalf Of Kathryn Mohror
Sent: Wednesday, May 22, 2013 2:16 PM
To: mpi3-tools at lists.mpi-forum.org
Subject: Re: [Mpi3-tools] latest draft of mqs
Comments inline
From: mpi3-tools-bounces at lists.mpi-forum.org<mailto:mpi3-tools-bounces at lists.mpi-forum.org> [mailto:mpi3-tools-bounces at lists.mpi-forum.org<mailto:tools-bounces at lists.mpi-forum.org>] On Behalf Of Kathryn Mohror
Sent: Wednesday, May 22, 2013 1:44 PM
To: mpi3-tools at lists.mpi-forum.org<mailto:mpi3-tools at lists.mpi-forum.org>
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 at lists.mpi-forum.org<mailto:mpi3-tools-bounces at lists.mpi-forum.org> [mailto:mpi3-tools-bounces at lists.mpi-forum.org<mailto:tools-bounces at lists.mpi-forum.org>] On Behalf Of Anh Vo
Sent: Wednesday, May 22, 2013 8:10 AM
To: mpi3-tools at lists.mpi-forum.org<mailto:mpi3-tools at lists.mpi-forum.org>
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 at lists.mpi-forum.org<mailto:mpi3-tools-bounces at lists.mpi-forum.org> [mailto:mpi3-tools-bounces at lists.mpi-forum.org<mailto:tools-bounces at lists.mpi-forum.org>] On Behalf Of Ahn, Dong H.
Sent: Wednesday, May 22, 2013 7:54 AM
To: mpi3-tools at lists.mpi-forum.org<mailto:mpi3-tools at lists.mpi-forum.org>
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 at lists.mpi-forum.org<mailto:mpi3-tools-bounces at lists.mpi-forum.org>
[mailto:mpi3-tools-bounces at lists.mpi-forum.org<mailto:tools-bounces at lists.mpi-forum.org>] On Behalf Of John
DelSignore
Sent: Wednesday, May 22, 2013 9:55 AM
To: mpi3-tools at lists.mpi-forum.org<mailto:mpi3-tools at lists.mpi-forum.org>
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 at lists.mpi-forum.org<mailto:mpi3-tools-bounces at lists.mpi-forum.org>
[mailto:mpi3-tools-bounces at lists.mpi-forum.org<mailto:tools-bounces at lists.mpi-forum.org>] *On Behalf Of
*Kathryn Mohror
*Sent:* Tuesday, May 21, 2013 6:27 PM
*To:* mpi3-tools at lists.mpi-forum.org<mailto:mpi3-tools at lists.mpi-forum.org>
*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 at roguewave.com<mailto:John.DelSignore at roguewave.com>
<mailto:John.DelSignore at roguewave.com>>
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 at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org> <mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
______________________________________________________________
Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>
<mailto:kathryn at llnl.gov>, http://people.llnl.gov/mohror1 CASC @
Lawrence Livermore National Laboratory, Livermore, CA, USA
_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
<msgq.pdf>_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
______________________________________________________________
Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>, http://people.llnl.gov/mohror1
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org<mailto:Mpi3-tools at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
______________________________________________________________
Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>, http://people.llnl.gov/mohror1
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20130523/c895b4e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msgq.pdf
Type: application/pdf
Size: 513271 bytes
Desc: msgq.pdf
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20130523/c895b4e3/attachment-0001.pdf>
More information about the mpiwg-tools
mailing list