Hi all,
sorry for missing the last meeting. As not to waste precious time during today's calls with initial questions regarding the current draft, I want to post the via email first:
-------------------
Wording: page 2, table 1.1
It is discouraged earlier that application developers use the MPIT interface, as it would come close to creating a performance tool within the 'self-tuning' application. Who is the 'end user' here? If it is an application developer, how does the desired information differ from what a performance tool (tuner) would like to see? Can anyone give an example?
-------------------
Wording: page 3, line 38
" … created and maintained …"
Creation sounds like "instantiation" to me, which might be a misleading here. Would '… specified …' be more clear?
-------------------
With all those query functions on page 4-5, do we have/need a function that can classify an MPI_Resource* to be of MPIT_MPI_RESOURCE_<some_type>?
-------------------
API: Page 5, line 6:
Shouldn't it be "MPI_Op" in the C prototype?
-------------------
API: Page 5, line 25:
Shouldn't it be "MPI_Win" in the C prototype?
-------------------
Wording: page 6, line 12:
… has to … -> … have to …
-------------------
Wording: in general, what is the exact meaning of "shall" in the standard. Is it equal to "must" or is it weaker?
(example: page 6, line 32)
-------------------
Wording: there are several passages where an "instance is instantiated" which reads a little tautologous. Wouldn't instances be 'created' (I would define instantiation as the creation of on instance). Might 'binding' be a word easier to understand what needs to be done as in "… a handle needs to be bound to a resource before first use …"
(example: page 11, line 29)
-------------------
Naming: page 11, line 35:
what is the exact meaning of 'index' here. What is it indexing? Is it an ID? If it is an index, which array does it refer to?
-------------------
Syntax: page 11, line 46:
superfluous whitespace before ','
-------------------
I haven't finished the complete draft yet, but wanted to post the mail sufficiently in advance to our call. If anything else is unclear, I will place that into a different email.
Cheers,
Marc-Andre
On 23.01.2011, at 23:04, Martin Schulz wrote:
> Hi all,
>
> Sorry for the late notice, but I assume that this is on your
> calendars anyway :) : the next tools WG TelCon is
> tomorrow as usual at 8am PDT, 11am EDT, 5pm MZ.
> As usual, Jeff has setup a Webex session. The link is:
>
> https://cisco.webex.com/cisco/j.php?ED=155386812&UID=0&PW=NMTJhNWQxOTdj&RT=…
> Password: tools
>
> We will discuss any more comments on the MPIT document.
> I have uploaded the latest version, which only has some minor
> changes compared to the version from two weeks ago.
>
> If you can't make it tomorrow, please send me any comments
> in the next few days. I will create a final draft by the end of
> the week and send it out to the forum as a whole to prepare
> them for the presentation at the next MPI forum meeting in
> two weeks.
>
> Talk to you all tomorrow,
>
> Martin
>
>
> ________________________________________________________________________
> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
--
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52056 Aachen | Germany
Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de
Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes
Hi all,
Sorry for the late notice, but I assume that this is on your
calendars anyway :) : the next tools WG TelCon is
tomorrow as usual at 8am PDT, 11am EDT, 5pm MZ.
As usual, Jeff has setup a Webex session. The link is:
https://cisco.webex.com/cisco/j.php?ED=155386812&UID=0&PW=NMTJhNWQxOTdj&RT=…
Password: tools
We will discuss any more comments on the MPIT document.
I have uploaded the latest version, which only has some minor
changes compared to the version from two weeks ago.
If you can't make it tomorrow, please send me any comments
in the next few days. I will create a final draft by the end of
the week and send it out to the forum as a whole to prepare
them for the presentation at the next MPI forum meeting in
two weeks.
Talk to you all tomorrow,
Martin
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
Hi all,
Just as a reminder - our next MPI-3 tools WG TelCon is scheduled
for Monday morning at the usual time (8am PST, 11am EST, 5pm MZ).
The main agenda point is to discuss the latest MPIT draft. The
access link is on the Wiki and as follows:
https://cisco.webex.com/cisco/j.php?ED=155386812&UID=0&PW=NMTJhNWQxOTdj&RT=…
Thanks to Kathryn and Dave for the feedback - comments and
replies are below. I also made matching changes to the text
and committed it to the SVN repo (in the new structure!). I also
uploaded it to the Wiki at:
https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/mpit
and attached it here.
Talk to you on Monday,
Martin
From Kathryn:
All small fixed from text file added.
> 1) I believe we decided that all of MPIT is available before MPI_Init, just that some variables may not exist or have valid values before MPI_Init (e.g. page 16, line 20). However, on page 1 line 48, it sounds to me like only MPIT_Init and MPIT_Finalize can be called outside of MPI_Init and MPI_Finalize.
> We should make sure that we clearly specify what is and is not allowed to be called outside of MPI_Init/Finalize.
Good point - that's not how it is meant, but that is how it reads.
I changed the text to reflect this.
>
> 2) On page 18, the perfvar start and stop routines return an error if not all variables are started when MPIT_PERFVAR_ALL_HANDLES is specified. I think that we decided that the routines would return MPIT_ERR_NOSTARTSTOP and that the user was responsible for looping through the variables starting or stopping them individually to find out where the problem was. If this is correct, we should explicitly state it. (This is also true for reset.)
I added a comment to each case.
>
> 3) At the start of the categories section, I think a brief example of variable categories and category hierarchies would go a long way. Without this intuition, I think the section will be somewhat confusing.
> Also, why does category_get_info return individual values for number of control vars, perf vars, and categories if the call to category_get_contents gives you no control over what is returned, just gives you "kinds" to sort out what is what. Maybe it should just return a content_count instead of the individual counts?
Let's leave this for discussion on Monday - hopefully Dave can
join us for this.
From Dave:
> section 1.2.2: can we cut "MPI_" from all of the "MPIT_MPI_RESOURCE_TYPE_BLAH" constants and related functions? These names seem unnecessarily wordy.
I am not a big fan of the names either, but the idea was to indicate
that these are MPIT constants, but MPI resources. I can go either
way here, but I would like to hear from the rest of the group before
I change it throughout the document.
>
> page 4: MPIT_MPI_RESOURCE_COMMUNICATOR takes an MPI_Comm as an IN parameter, but the binding has a pointer as the type. Same goes for all of the other similar functions on this page.
The idea is to allow simple pointer conversion implementations,
which I would expect many would want to do. If we remove the
"*" this would no longer be possible. The IN should indicate,
though, that the argument is not being modified. Is there a
better way to do this? I guess, this is mainly a question for the
implementors.
>
> page 4, line 33: "MPI_" should be "MPI_Group"
fixed.
>
> page 5, line 29: "MPIT_MPI_Resource*" seems to be in the wrong typeface. This is a C language type, so it should be typewriter text.
It has the right macro - I'll have to double check this with
the rest of the standard.
>
> General comment about this section and functionality: Since we assume only C bindings, can we just replace all of these functions with a single function? Something like:
>
> MPIT_Get_resource(void *handle_ptr, int resource_type, MPIT_MPI_Resource *out_resource);
>
> and a call to it would look something like this:
> -----8<----
> int type;
> int index = 0;
> MPIT_MPI_Resource resource;
> MPIT_Controlvar_handle handle;
> MPI_Comm comm = MPI_COMM_SELF;
> MPIT_Controlvar_get_info(index, ..., &type, ...);
> if (type == MPIT_MPI_RESOURCE_TYPE_COMMUNICATOR) {
> MPIT_Get_resource(&comm, type, &resource);
> MPIT_Controlvar_handle_allocate(index, resource, &handle);
> /* read, write, etc here using handle */
> }
> -----8<----
That's pretty close to what I had last time, but I had the feeling that
the majority didn't like that and instead wanted a type safe option
as the current one. Any other comments on this one? Both options
would work and each has their pluses and minuses.
>
> I think the string arguments section (1.2.3) could use just a little polishing to make its behavior crystal clear, but it's much better than it was. Also, "deposits"-->"writes".
I replaced deposits with writes - besides that, do you have any concrete
suggestions or do you think anything particular may be unclear? I have
seen this now so often that I have a hard time telling.
>
> I'll admit I didn't have time to thoroughly read the perfvar section, so there might still be issues there.
>
> As for the category section, it looks basically OK to me. I thought that we decided at the last call that categories would be flat and wouldn't contain other categories. If you insist on pursuing this approach further, you'll need more text to explain that categories can't contain each other or themselves cyclically.
I thought we decided for including them, but perhaps this was
just my preference. I still think it can't hurt and gives us that
little extra flexibility. I agree, though, if we go that route we
need to make these restrictions clear. I added some text
for this purpose.
>
> A general language comment: you should basically do a search and replace of "have to" or "has to" with "must" throughout the document.
fixed
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
My comments so far:
section 1.2.2: can we cut "MPI_" from all of the "MPIT_MPI_RESOURCE_TYPE_BLAH" constants and related functions? These names seem unnecessarily wordy.
page 4: MPIT_MPI_RESOURCE_COMMUNICATOR takes an MPI_Comm as an IN parameter, but the binding has a pointer as the type. Same goes for all of the other similar functions on this page.
page 4, line 33: "MPI_" should be "MPI_Group"
page 5, line 29: "MPIT_MPI_Resource*" seems to be in the wrong typeface. This is a C language type, so it should be typewriter text.
General comment about this section and functionality: Since we assume only C bindings, can we just replace all of these functions with a single function? Something like:
MPIT_Get_resource(void *handle_ptr, int resource_type, MPIT_MPI_Resource *out_resource);
and a call to it would look something like this:
-----8<----
int type;
int index = 0;
MPIT_MPI_Resource resource;
MPIT_Controlvar_handle handle;
MPI_Comm comm = MPI_COMM_SELF;
MPIT_Controlvar_get_info(index, ..., &type, ...);
if (type == MPIT_MPI_RESOURCE_TYPE_COMMUNICATOR) {
MPIT_Get_resource(&comm, type, &resource);
MPIT_Controlvar_handle_allocate(index, resource, &handle);
/* read, write, etc here using handle */
}
-----8<----
I think the string arguments section (1.2.3) could use just a little polishing to make its behavior crystal clear, but it's much better than it was. Also, "deposits"-->"writes".
I'll admit I didn't have time to thoroughly read the perfvar section, so there might still be issues there.
As for the category section, it looks basically OK to me. I thought that we decided at the last call that categories would be flat and wouldn't contain other categories. If you insist on pursuing this approach further, you'll need more text to explain that categories can't contain each other or themselves cyclically.
A general language comment: you should basically do a search and replace of "have to" or "has to" with "must" throughout the document.
-Dave
On Jan 4, 2011, at 3:35 AM CST, Martin Schulz wrote:
> Hi all,
>
> Happy new year!
>
> This is just a quick reminder that we have the next MPI-3 tools
> TelCon scheduled for next Monday 1/10/11 at 8am PT, 11am
> ET, 5pm MEZ. The main point on the agenda is to continue
> going through the MPIT document.
>
> I habe uploaded a new version of the MPIT draft (with changebars
> compared to the December version) to the MPI-3 tools WG Wiki at
>
> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Tools/mpit/
>
> It (hopefully) contains all change requests - if I forgot something,
> please let me know. The document should be now more or less
> complete - I updated also the performance variable section and
> the categories (Dave, I adjusted this to match the rest of the
> document - could you please check this over if this matches with
> what you remember from the discussion last month?).
>
> The main open issue is the addition of examples, which I'll do
> as soon as I get to it. Any suggestions for this are welcome.
> Also the error/return code table at the end probably needs
> some entries to be complete.
>
> The document purposely does not contain the PMPI section of
> the tools chapter, yet, since this currently still the old version and
> also causes some strange Latex error caused by the change
> bar macros. If anyone knows how to fix this, that would be great
> (the macros also still add some arbitrary spaces, which I don't
> know how to remove - anyone any ideas?). I will update this
> once we have a new golden copy of the PMPI part with the
> currently proposed updates.
>
> Please let me know if you have any comments on the new
> draft or see anything missing.
>
> Thanks!
>
> Martin
>
>
>
>
> ________________________________________________________________________
> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
Hi Martin, all,
I attached a text file that has a few minor corrections, mostly grammar and typos. I also have a few other questions:
1) I believe we decided that all of MPIT is available before MPI_Init, just that some variables may not exist or have valid values before MPI_Init (e.g. page 16, line 20). However, on page 1 line 48, it sounds to me like only MPIT_Init and MPIT_Finalize can be called outside of MPI_Init and MPI_Finalize.
We should make sure that we clearly specify what is and is not allowed to be called outside of MPI_Init/Finalize.
2) On page 18, the perfvar start and stop routines return an error if not all variables are started when MPIT_PERFVAR_ALL_HANDLES is specified. I think that we decided that the routines would return MPIT_ERR_NOSTARTSTOP and that the user was responsible for looping through the variables starting or stopping them individually to find out where the problem was. If this is correct, we should explicitly state it. (This is also true for reset.)
3) At the start of the categories section, I think a brief example of variable categories and category hierarchies would go a long way. Without this intuition, I think the section will be somewhat confusing.
Also, why does category_get_info return individual values for number of control vars, perf vars, and categories if the call to category_get_contents gives you no control over what is returned, just gives you "kinds" to sort out what is what. Maybe it should just return a content_count instead of the individual counts?
Kathryn
> -----Original Message-----
> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools-
> bounces(a)lists.mpi-forum.org] On Behalf Of Martin Schulz
> Sent: Tuesday, January 04, 2011 1:35 AM
> To: MPI3 Tools
> Subject: [Mpi3-tools] New MPIT draft and next TelCon
>
> Hi all,
>
> Happy new year!
>
> This is just a quick reminder that we have the next MPI-3 tools
> TelCon scheduled for next Monday 1/10/11 at 8am PT, 11am
> ET, 5pm MEZ. The main point on the agenda is to continue
> going through the MPIT document.
>
> I habe uploaded a new version of the MPIT draft (with changebars
> compared to the December version) to the MPI-3 tools WG Wiki at
>
> https://svn.mpi-forum.org/trac/mpi-forum-
> web/attachment/wiki/MPI3Tools/mpit/
>
> It (hopefully) contains all change requests - if I forgot something,
> please let me know. The document should be now more or less
> complete - I updated also the performance variable section and
> the categories (Dave, I adjusted this to match the rest of the
> document - could you please check this over if this matches with
> what you remember from the discussion last month?).
>
> The main open issue is the addition of examples, which I'll do
> as soon as I get to it. Any suggestions for this are welcome.
> Also the error/return code table at the end probably needs
> some entries to be complete.
>
> The document purposely does not contain the PMPI section of
> the tools chapter, yet, since this currently still the old version and
> also causes some strange Latex error caused by the change
> bar macros. If anyone knows how to fix this, that would be great
> (the macros also still add some arbitrary spaces, which I don't
> know how to remove - anyone any ideas?). I will update this
> once we have a new golden copy of the PMPI part with the
> currently proposed updates.
>
> Please let me know if you have any comments on the new
> draft or see anything missing.
>
> Thanks!
>
> Martin
>
>
>
>
> ______________________________________________________________________
> __
> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
Hi all,
Happy new year!
This is just a quick reminder that we have the next MPI-3 tools
TelCon scheduled for next Monday 1/10/11 at 8am PT, 11am
ET, 5pm MEZ. The main point on the agenda is to continue
going through the MPIT document.
I habe uploaded a new version of the MPIT draft (with changebars
compared to the December version) to the MPI-3 tools WG Wiki at
https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Tools/mpit/
It (hopefully) contains all change requests - if I forgot something,
please let me know. The document should be now more or less
complete - I updated also the performance variable section and
the categories (Dave, I adjusted this to match the rest of the
document - could you please check this over if this matches with
what you remember from the discussion last month?).
The main open issue is the addition of examples, which I'll do
as soon as I get to it. Any suggestions for this are welcome.
Also the error/return code table at the end probably needs
some entries to be complete.
The document purposely does not contain the PMPI section of
the tools chapter, yet, since this currently still the old version and
also causes some strange Latex error caused by the change
bar macros. If anyone knows how to fix this, that would be great
(the macros also still add some arbitrary spaces, which I don't
know how to remove - anyone any ideas?). I will update this
once we have a new golden copy of the PMPI part with the
currently proposed updates.
Please let me know if you have any comments on the new
draft or see anything missing.
Thanks!
Martin
________________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
