February 2016 - mpiwg-p2p - mailman3.cels.anl.gov

Re: [mpiwg-p2p] Next meeting: TODAY at 11am US Central
by Jeff Hammond 15 Feb '16

15 Feb '16

Are we meeting today? On Mon, Feb 1, 2016 at 10:11 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi all, > > Meeting notes (with actions) now up on the wiki at: > https://github.com/mpiwg-p2p/p2p-issues/wiki/notes-2016-02-01 > > Cheers, > Dan. > > > On 01/02/2016 13:19, Daniel Holmes wrote: > >> Hi all, >> >> The next teleconference will be today at 11am US Central time via webex. >> Connection information can be found on the wiki page at: >> https://github.com/mpiwg-p2p/p2p-issues/wiki >> >> Agenda: >> 1) Discuss and agree text changes for issue #26 "deprecate send cancel" >> 2) Update status for issue #11 "info assertions" >> 3) Update status for issue #32 "allocating receive and freeing send" >> >> I'd like to get all three of these issues ready for reading/voting in >> time for the next meeting. Today is 2 weeks before the 2 week deadline, >> i.e. this is final meeting with time after it to take action before the >> cut-off for the next face-to-face meeting. >> >> Cheers, >> Dan. >> >> > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-p2p] Info assertions draft
by Jim Dinan 12 Feb '16

12 Feb '16

Hi Hubert, Thanks for the feedback. The language we used in the proposal is consistent with the existing spec. I think I would prefer to let the Hybrid WG make this change when the Forum decides to move ahead with their renaming proposal. ~Jim. On Fri, Feb 12, 2016 at 6:05 AM, Hubert Ritzdorf < Hubert.Ritzdorf(a)emea.nec.com> wrote: > Hi, > > in conjunction with the process discussion in the hybrid group: > > Wouldn't it make sense to replace "process" by "MPI process" in the new > text on Pages 249-250 ? > > Hubert > ------------------------------ > *From:* mpiwg-p2p [mpiwg-p2p-bounces(a)lists.mpi-forum.org] on behalf of > Jim Dinan [james.dinan(a)gmail.com] > *Sent:* Tuesday, February 09, 2016 9:40 PM > *To:* MPI WG Point To Point Communications working group > *Subject:* [mpiwg-p2p] Info assertions draft > > Hi All, > > I have attached an updated draft for the info assertions proposal. The > two week deadline is quickly approaching; please send feedback before the > end of the week. > > Thanks, > ~Jim. > > > Click here > <https://www.mailcontrol.com/sr/+xpPmuWT7LDWQxILzJ5p9zsHlc6Ch4!k4z!cQRfe9O+Z…> > to report this email as spam. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >

1 0

Re: [mpiwg-p2p] Info assertions draft
by Hubert Ritzdorf 12 Feb '16

12 Feb '16

Hi, in conjunction with the process discussion in the hybrid group: Wouldn't it make sense to replace "process" by "MPI process" in the new text on Pages 249-250 ? Hubert ________________________________ From: mpiwg-p2p [mpiwg-p2p-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [james.dinan(a)gmail.com] Sent: Tuesday, February 09, 2016 9:40 PM To: MPI WG Point To Point Communications working group Subject: [mpiwg-p2p] Info assertions draft Hi All, I have attached an updated draft for the info assertions proposal. The two week deadline is quickly approaching; please send feedback before the end of the week. Thanks, ~Jim. Click here<https://www.mailcontrol.com/sr/+xpPmuWT7LDWQxILzJ5p9zsHlc6Ch4!k4z!cQRfe9O+Z…> to report this email as spam.

1 0

Re: [mpiwg-p2p] Info assertions draft
by Jim Dinan 10 Feb '16

10 Feb '16

I generated a new pull request and updated the PDF on the ticket. Still plenty of time for changes, but I wanted to make sure I don't forget to post the updated proposal. On Tue, Feb 9, 2016 at 3:40 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > I have attached an updated draft for the info assertions proposal. The > two week deadline is quickly approaching; please send feedback before the > end of the week. > > Thanks, > ~Jim. >

1 0

Re: [mpiwg-p2p] Message matching for tools
by Marc-Andre Hermanns 10 Feb '16

10 Feb '16

Hi George, sorry, was on leave for the last couple of days due to the "street carnival" (https://en.wikipedia.org/wiki/Carnival_in_Germany,_Switzerland_and_Austria#…) > Assuming that the usual precautions are taken, aka. tools and > libraries create their own communicators, I fail to see how the user > hints on it's communicators can have any impact on libraries/tools ? As Jim already pointed out in his reply, the problem arises when we try to match messages solely on the envelope information. With this assertion active, correct message matching in a replay as done by Scalasca cannot be guaranteed, and neither can the wrong matching be detected. During the course of this discussion we agreed that this is not a concern for the P2P working group, but the tools working group will have to come up with something that mitigates the problem. I don't know, if we need to modify the "Advice to users", though. Because, once we found a way around the problem, we would could drop the addition again. Thus, it would only be a temporary addition to the standard, which I don't like very much. My idea for an interim solution would be that the measurement tool checks for the assertion and then points the user to additional (non-standard) info hints---ignored by the MPI but seen by the tool---that provide further guarantees for the tool. Something along the lines of "scorep_deterministic_matching = true/false". The tool would document this accordingly. What do you think? Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Schinkelstrasse 2 52062 Aachen Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-p2p] Message matching for tools
by Jim Dinan 09 Feb '16

09 Feb '16

Hi George, That's a good point, that tools may also be impacted through the global communicators. With this sentence we had wanted to (tactfully) get at the fact that tools which analyze the communication pattern of the application (e.g. using the profiling interface to intercept calls and reconstruct the matching order) may be confounded if the user sets the allow_overtaking info key. ~Jim. On Tue, Feb 9, 2016 at 6:38 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: > On Wed, Feb 10, 2016 at 12:44 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> > wrote: > >> Hi George, >> >> However, the effect on tools is not limited to global objects such as the >> predefined communicators - the semantics are changed for *any* communicator >> on which these info assertions are set. Your "and tools" bit is therefore >> necessary but not sufficient. >> > > Assuming that the usual precautions are taken, aka. tools and libraries > create their own communicators, I fail to see how the user hints on it's > communicators can have any impact on libraries/tools ? > > Moreover, as there is no way in MPI to get access to a communicator you > don't see a reference (except MPI_COMM_WORLD and SELF), the user has no > practical solution to set hints on a communicator that do no belong to her. > The opposite is however always true. Because libraries and the tools have > access to at least some of the application communicators, by setting hints > on such a communicator (and in the case of tools we are talking about all > communicators) they can affect the performance of the application. > > I believe Jim has now changed the wording of the sentence you are >> concerned about back to a previous version, i.e. "The usage of info hints >> may also impact the effectiveness of tools." Does that alleviate your >> concern? >> > > This is exactly the sentence that raise my concerns. Tools communicators > are invisible to all other software layers in the application (obviously > excluding other tools), and as such the particular sentence you mention has > no meaning. > > George. > > > >> >> Cheers, >> Dan. >> >> >> On 09/02/2016 22:36, George Bosilca wrote: >> >> Sorry to jump in the middle (or the end) of the discussion. From my "MPI >> user" point of view, the last part of the proposed advice is unsettling. >> >> "The usage of some info hints may allow the MPI library to change its >> behavior and, as a result, impact the effectiveness of tools." >> >> seems to have a broader scope, and includes application developers, when >> the most obvious target should have been tools developers. I think removing >> the last part and emphasizing tools and libraries, makes a more clear point. >> >> "Setting info hints on the predefined communicators \const{MPI\_COMM\_ >> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >> changes to these global objects may affect all components of the >> application, including libraries and tools." >> >> George. >> >> >> On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >>> We're calling the proposal "info assertions", but the standard still >>> refers to them as "hints". >>> >>> Reading the proposed change again, I think it might be helpful (and more >>> fair to tools) to say why info could impact tools: >>> >>> Setting info hints on the predefined communicators \const{MPI\_COMM\_ >>> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >>> changes to these global objects may affect all components of the >>> application, including libraries. The usage of some info hints may >>> allow the MPI library to change its behavior and, as a result, impact the >>> effectiveness of tools. >>> >>> ~Jim. >>> >>> On Tue, Feb 9, 2016 at 12:38 PM, Daniel Holmes < <dholmes(a)epcc.ed.ac.uk> >>> dholmes(a)epcc.ed.ac.uk> wrote: >>> >>>> Hi Jim, >>>> >>>> I like that change. On a side note: are we really still calling them >>>> "info hints" in this context rather than "info assertions"? >>>> >>>> Cheers, >>>> Dan. >>>> >>>> >>>> On 09/02/2016 15:51, Jim Dinan wrote: >>>> >>>> Hi All, >>>> >>>> I'm preparing the updated draft of info assertions for a reading in >>>> March. Where did we land on an advice regarding tools? Do we want advice >>>> (1) to users, that they info keys may impact tools and/or (2) to tools that >>>> they should check info? >>>> >>>> For instance, we could extend the current advice with the following >>>> sentence: >>>> >>>> Setting info hints on the predefined communicators \const{MPI\_COMM\_ >>>> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >>>> changes to these global objects may affect all components of the >>>> application, including libraries. The usage of info hints may also >>>> impact the effectiveness of tools. >>>> >>>> ~Jim. >>>> >>>> On Fri, Dec 18, 2015 at 5:24 AM, Marc-Andre Hermanns < >>>> <hermanns(a)jara.rwth-aachen.de>hermanns(a)jara.rwth-aachen.de> wrote: >>>> >>>>> Hi Jeff, >>>>> >>>>> > at the moment we don't handle MPI_THREAD_MULTIPLE at all. But we >>>>> want >>>>> > to get there ;-) >>>>> > >>>>> > >>>>> > You should vote for endpoints, as this may help you out here, >>>>> > particularly if users start mapping endpoints 1:1 w/ threads. >>>>> >>>>> That would certainly ease things for us in these situations. >>>>> Unfortunately endpoints force use to adapt other infrastructure in our >>>>> measurement system. >>>>> >>>>> > b) Creating a derived datatype on the fly to add tool-level data >>>>> to >>>>> > the original payload may induce a large overhead in practically >>>>> > _every_ send & receive operation and perturb the measurement. >>>>> > >>>>> > >>>>> > You should evaluate this experimentally. I wrote a simple test >>>>> > ( >>>>> https://github.com/jeffhammond/BigMPI/blob/master/test/perf/typepiggy.c >>>>> ) >>>>> > and measured 1.5 us per call of overhead to create a datatype. That >>>>> > is not significant except for very small messages. >>>>> >>>>> Thanks for the pointer. You are right. I should evaluate this further. >>>>> 1.5us does indeed seem tolerable. I wonder how the influence of the >>>>> derived datatype is on overall messaging performance, though. >>>>> >>>>> This is also something I should evaluate in the process. >>>>> >>>>> Cheers, >>>>> Marc-Andre >>>>> >>>>> -- >>>>> Marc-Andre Hermanns >>>>> Jülich Aachen Research Alliance, >>>>> High Performance Computing (JARA-HPC) >>>>> Jülich Supercomputing Centre (JSC) >>>>> >>>>> Schinkelstrasse 2 >>>>> 52062 Aachen >>>>> Germany >>>>> >>>>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>>>> Fax: +49 2461 80 6 99753 <%2B49%202461%2080%206%2099753> >>>>> www.jara.org/jara-hpc >>>>> email: <hermanns(a)jara.rwth-aachen.de>hermanns(a)jara.rwth-aachen.de >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-p2p mailing list >>>>> mpiwg-p2p(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-p2p mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>>> >>>> >>>> -- >>>> Dan Holmes >>>> Applications Consultant in HPC Research >>>> EPCC, The University of Edinburgh >>>> James Clerk Maxwell Building >>>> The Kings Buildings >>>> Peter Guthrie Tait Road >>>> Edinburgh >>>> EH9 3FD >>>> T: +44(0)131 651 3465 >>>> E: dholmes(a)epcc.ed.ac.uk >>>> >>>> *Please consider the environment before printing this email.* >>>> >>>> >>>> The University of Edinburgh is a charitable body, registered in >>>> Scotland, with registration number SC005336. >>>> >>>> _______________________________________________ >>>> mpiwg-p2p mailing list >>>> mpiwg-p2p(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>>> >>> >>> >>> _______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>> >> >> >> -- >> Dan Holmes >> Applications Consultant in HPC Research >> EPCC, The University of Edinburgh >> James Clerk Maxwell Building >> The Kings Buildings >> Peter Guthrie Tait Road >> Edinburgh >> EH9 3FD >> T: +44(0)131 651 3465 >> E: dholmes(a)epcc.ed.ac.uk >> >> *Please consider the environment before printing this email.* >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >

1 0

Re: [mpiwg-p2p] Message matching for tools
by George Bosilca 09 Feb '16

09 Feb '16

On Wed, Feb 10, 2016 at 12:44 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi George, > > However, the effect on tools is not limited to global objects such as the > predefined communicators - the semantics are changed for *any* communicator > on which these info assertions are set. Your "and tools" bit is therefore > necessary but not sufficient. > Assuming that the usual precautions are taken, aka. tools and libraries create their own communicators, I fail to see how the user hints on it's communicators can have any impact on libraries/tools ? Moreover, as there is no way in MPI to get access to a communicator you don't see a reference (except MPI_COMM_WORLD and SELF), the user has no practical solution to set hints on a communicator that do no belong to her. The opposite is however always true. Because libraries and the tools have access to at least some of the application communicators, by setting hints on such a communicator (and in the case of tools we are talking about all communicators) they can affect the performance of the application. I believe Jim has now changed the wording of the sentence you are concerned > about back to a previous version, i.e. "The usage of info hints may also > impact the effectiveness of tools." Does that alleviate your concern? > This is exactly the sentence that raise my concerns. Tools communicators are invisible to all other software layers in the application (obviously excluding other tools), and as such the particular sentence you mention has no meaning. George. > > Cheers, > Dan. > > > On 09/02/2016 22:36, George Bosilca wrote: > > Sorry to jump in the middle (or the end) of the discussion. From my "MPI > user" point of view, the last part of the proposed advice is unsettling. > > "The usage of some info hints may allow the MPI library to change its > behavior and, as a result, impact the effectiveness of tools." > > seems to have a broader scope, and includes application developers, when > the most obvious target should have been tools developers. I think removing > the last part and emphasizing tools and libraries, makes a more clear point. > > "Setting info hints on the predefined communicators \const{MPI\_COMM\_ > WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as > changes to these global objects may affect all components of the > application, including libraries and tools." > > George. > > > On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> We're calling the proposal "info assertions", but the standard still >> refers to them as "hints". >> >> Reading the proposed change again, I think it might be helpful (and more >> fair to tools) to say why info could impact tools: >> >> Setting info hints on the predefined communicators \const{MPI\_COMM\_ >> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >> changes to these global objects may affect all components of the >> application, including libraries. The usage of some info hints may >> allow the MPI library to change its behavior and, as a result, impact the >> effectiveness of tools. >> >> ~Jim. >> >> On Tue, Feb 9, 2016 at 12:38 PM, Daniel Holmes < <dholmes(a)epcc.ed.ac.uk> >> dholmes(a)epcc.ed.ac.uk> wrote: >> >>> Hi Jim, >>> >>> I like that change. On a side note: are we really still calling them >>> "info hints" in this context rather than "info assertions"? >>> >>> Cheers, >>> Dan. >>> >>> >>> On 09/02/2016 15:51, Jim Dinan wrote: >>> >>> Hi All, >>> >>> I'm preparing the updated draft of info assertions for a reading in >>> March. Where did we land on an advice regarding tools? Do we want advice >>> (1) to users, that they info keys may impact tools and/or (2) to tools that >>> they should check info? >>> >>> For instance, we could extend the current advice with the following >>> sentence: >>> >>> Setting info hints on the predefined communicators \const{MPI\_COMM\_ >>> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >>> changes to these global objects may affect all components of the >>> application, including libraries. The usage of info hints may also >>> impact the effectiveness of tools. >>> >>> ~Jim. >>> >>> On Fri, Dec 18, 2015 at 5:24 AM, Marc-Andre Hermanns < >>> <hermanns(a)jara.rwth-aachen.de>hermanns(a)jara.rwth-aachen.de> wrote: >>> >>>> Hi Jeff, >>>> >>>> > at the moment we don't handle MPI_THREAD_MULTIPLE at all. But we >>>> want >>>> > to get there ;-) >>>> > >>>> > >>>> > You should vote for endpoints, as this may help you out here, >>>> > particularly if users start mapping endpoints 1:1 w/ threads. >>>> >>>> That would certainly ease things for us in these situations. >>>> Unfortunately endpoints force use to adapt other infrastructure in our >>>> measurement system. >>>> >>>> > b) Creating a derived datatype on the fly to add tool-level data >>>> to >>>> > the original payload may induce a large overhead in practically >>>> > _every_ send & receive operation and perturb the measurement. >>>> > >>>> > >>>> > You should evaluate this experimentally. I wrote a simple test >>>> > ( >>>> https://github.com/jeffhammond/BigMPI/blob/master/test/perf/typepiggy.c >>>> ) >>>> > and measured 1.5 us per call of overhead to create a datatype. That >>>> > is not significant except for very small messages. >>>> >>>> Thanks for the pointer. You are right. I should evaluate this further. >>>> 1.5us does indeed seem tolerable. I wonder how the influence of the >>>> derived datatype is on overall messaging performance, though. >>>> >>>> This is also something I should evaluate in the process. >>>> >>>> Cheers, >>>> Marc-Andre >>>> >>>> -- >>>> Marc-Andre Hermanns >>>> Jülich Aachen Research Alliance, >>>> High Performance Computing (JARA-HPC) >>>> Jülich Supercomputing Centre (JSC) >>>> >>>> Schinkelstrasse 2 >>>> 52062 Aachen >>>> Germany >>>> >>>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>>> Fax: +49 2461 80 6 99753 <%2B49%202461%2080%206%2099753> >>>> www.jara.org/jara-hpc >>>> email: <hermanns(a)jara.rwth-aachen.de>hermanns(a)jara.rwth-aachen.de >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-p2p mailing list >>>> mpiwg-p2p(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-p2p mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>> >>> >>> -- >>> Dan Holmes >>> Applications Consultant in HPC Research >>> EPCC, The University of Edinburgh >>> James Clerk Maxwell Building >>> The Kings Buildings >>> Peter Guthrie Tait Road >>> Edinburgh >>> EH9 3FD >>> T: +44(0)131 651 3465 >>> E: dholmes(a)epcc.ed.ac.uk >>> >>> *Please consider the environment before printing this email.* >>> >>> >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> _______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>> >> >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> > > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > >

1 0

Re: [mpiwg-p2p] Message matching for tools
by Daniel Holmes 09 Feb '16

09 Feb '16

Hi George, However, the effect on tools is not limited to global objects such as the predefined communicators - the semantics are changed for *any* communicator on which these info assertions are set. Your "and tools" bit is therefore necessary but not sufficient. I believe Jim has now changed the wording of the sentence you are concerned about back to a previous version, i.e. "The usage of info hints may also impact the effectiveness of tools." Does that alleviate your concern? Cheers, Dan. On 09/02/2016 22:36, George Bosilca wrote: > Sorry to jump in the middle (or the end) of the discussion. From my > "MPI user" point of view, the last part of the proposed advice is > unsettling. > > "The usage of some info hints may allow the MPI library to change its > behavior and, as a result, impact the effectiveness of tools." > > seems to have a broader scope, and includes application developers, > when the most obvious target should have been tools developers. I > think removing the last part and emphasizing tools and libraries, > makes a more clear point. > > "Setting info hints on the predefined communicators > \const{MPI\_COMM\_WORLD} and \const{MPI\_COMM\_SELF} may have > unintended effects, as changes to these global objects may affect all > components of the application, including libraries and tools." > > George. > > > On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan(a)gmail.com > <mailto:[email protected]>> wrote: > > We're calling the proposal "info assertions", but the standard > still refers to them as "hints". > > Reading the proposed change again, I think it might be helpful > (and more fair to tools) to say why info could impact tools: > > Setting info hints on the predefined communicators > \const{MPI\_COMM\_WORLD} and \const{MPI\_COMM\_SELF} may have > unintended effects, as changes to these global objects may > affect all components of the application, including libraries. > The usage of some info hints may allow the MPI library to > change its behavior and, as a result, impact the effectiveness > of tools. > > ~Jim. > > On Tue, Feb 9, 2016 at 12:38 PM, Daniel Holmes > <dholmes(a)epcc.ed.ac.uk <mailto:[email protected]>> wrote: > > Hi Jim, > > I like that change. On a side note: are we really still > calling them "info hints" in this context rather than "info > assertions"? > > Cheers, > Dan. > > > On 09/02/2016 15:51, Jim Dinan wrote: >> Hi All, >> >> I'm preparing the updated draft of info assertions for a >> reading in March. Where did we land on an advice regarding >> tools? Do we want advice (1) to users, that they info keys >> may impact tools and/or (2) to tools that they should check info? >> >> For instance, we could extend the current advice with the >> following sentence: >> >> Setting info hints on the predefined communicators >> \const{MPI\_COMM\_WORLD} and \const{MPI\_COMM\_SELF}may have >> unintended effects, as changes to these global objects may >> affect all components of the application, including >> libraries. The usage of info hints may also impact the >> effectiveness of tools. >> >> ~Jim. >> >> On Fri, Dec 18, 2015 at 5:24 AM, Marc-Andre Hermanns >> <hermanns(a)jara.rwth-aachen.de >> <mailto:[email protected]>> wrote: >> >> Hi Jeff, >> >> > at the moment we don't handle MPI_THREAD_MULTIPLE >> at all. But we want >> > to get there ;-) >> > >> > >> > You should vote for endpoints, as this may help you out >> here, >> > particularly if users start mapping endpoints 1:1 w/ >> threads. >> >> That would certainly ease things for us in these situations. >> Unfortunately endpoints force use to adapt other >> infrastructure in our >> measurement system. >> >> > b) Creating a derived datatype on the fly to add >> tool-level data to >> > the original payload may induce a large overhead in >> practically >> > _every_ send & receive operation and perturb the >> measurement. >> > >> > >> > You should evaluate this experimentally. I wrote a >> simple test >> > >> (https://github.com/jeffhammond/BigMPI/blob/master/test/perf/typepiggy.c) >> > and measured 1.5 us per call of overhead to create a >> datatype. That >> > is not significant except for very small messages. >> >> Thanks for the pointer. You are right. I should evaluate >> this further. >> 1.5us does indeed seem tolerable. I wonder how the >> influence of the >> derived datatype is on overall messaging performance, though. >> >> This is also something I should evaluate in the process. >> >> Cheers, >> Marc-Andre >> >> -- >> Marc-Andre Hermanns >> Jülich Aachen Research Alliance, >> High Performance Computing (JARA-HPC) >> Jülich Supercomputing Centre (JSC) >> >> Schinkelstrasse 2 >> 52062 Aachen >> Germany >> >> Phone: +49 2461 61 2509 <tel:%2B49%202461%2061%202509> | >> +49 241 80 24381 <tel:%2B49%20241%2080%2024381> >> Fax: +49 2461 80 6 99753 <tel:%2B49%202461%2080%206%2099753> >> www.jara.org/jara-hpc <http://www.jara.org/jara-hpc> >> email: hermanns(a)jara.rwth-aachen.de >> <mailto:[email protected]> >> >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> >> >> >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T:+44(0)131 651 3465 <tel:%2B44%280%29131%20651%203465> > E:[email protected] <mailto:[email protected]> > > *Please consider the environment before printing this email.* > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-p2p] Message matching for tools
by George Bosilca 09 Feb '16

09 Feb '16

Sorry to jump in the middle (or the end) of the discussion. From my "MPI user" point of view, the last part of the proposed advice is unsettling. "The usage of some info hints may allow the MPI library to change its behavior and, as a result, impact the effectiveness of tools." seems to have a broader scope, and includes application developers, when the most obvious target should have been tools developers. I think removing the last part and emphasizing tools and libraries, makes a more clear point. "Setting info hints on the predefined communicators \const{MPI\_COMM\_WORLD } and \const{MPI\_COMM\_SELF} may have unintended effects, as changes to these global objects may affect all components of the application, including libraries and tools." George. On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > We're calling the proposal "info assertions", but the standard still > refers to them as "hints". > > Reading the proposed change again, I think it might be helpful (and more > fair to tools) to say why info could impact tools: > > Setting info hints on the predefined communicators \const{MPI\_COMM\_WORLD > } and \const{MPI\_COMM\_SELF} may have unintended effects, as changes to > these global objects may affect all components of the application, > including libraries. The usage of some info hints may allow the MPI > library to change its behavior and, as a result, impact the effectiveness > of tools. > > ~Jim. > > On Tue, Feb 9, 2016 at 12:38 PM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> > wrote: > >> Hi Jim, >> >> I like that change. On a side note: are we really still calling them >> "info hints" in this context rather than "info assertions"? >> >> Cheers, >> Dan. >> >> >> On 09/02/2016 15:51, Jim Dinan wrote: >> >> Hi All, >> >> I'm preparing the updated draft of info assertions for a reading in >> March. Where did we land on an advice regarding tools? Do we want advice >> (1) to users, that they info keys may impact tools and/or (2) to tools that >> they should check info? >> >> For instance, we could extend the current advice with the following >> sentence: >> >> Setting info hints on the predefined communicators \const{MPI\_COMM\_ >> WORLD} and \const{MPI\_COMM\_SELF} may have unintended effects, as >> changes to these global objects may affect all components of the >> application, including libraries. The usage of info hints may also >> impact the effectiveness of tools. >> >> ~Jim. >> >> On Fri, Dec 18, 2015 at 5:24 AM, Marc-Andre Hermanns < >> <hermanns(a)jara.rwth-aachen.de>hermanns(a)jara.rwth-aachen.de> wrote: >> >>> Hi Jeff, >>> >>> > at the moment we don't handle MPI_THREAD_MULTIPLE at all. But we >>> want >>> > to get there ;-) >>> > >>> > >>> > You should vote for endpoints, as this may help you out here, >>> > particularly if users start mapping endpoints 1:1 w/ threads. >>> >>> That would certainly ease things for us in these situations. >>> Unfortunately endpoints force use to adapt other infrastructure in our >>> measurement system. >>> >>> > b) Creating a derived datatype on the fly to add tool-level data to >>> > the original payload may induce a large overhead in practically >>> > _every_ send & receive operation and perturb the measurement. >>> > >>> > >>> > You should evaluate this experimentally. I wrote a simple test >>> > ( >>> https://github.com/jeffhammond/BigMPI/blob/master/test/perf/typepiggy.c) >>> > and measured 1.5 us per call of overhead to create a datatype. That >>> > is not significant except for very small messages. >>> >>> Thanks for the pointer. You are right. I should evaluate this further. >>> 1.5us does indeed seem tolerable. I wonder how the influence of the >>> derived datatype is on overall messaging performance, though. >>> >>> This is also something I should evaluate in the process. >>> >>> Cheers, >>> Marc-Andre >>> >>> -- >>> Marc-Andre Hermanns >>> Jülich Aachen Research Alliance, >>> High Performance Computing (JARA-HPC) >>> Jülich Supercomputing Centre (JSC) >>> >>> Schinkelstrasse 2 >>> 52062 Aachen >>> Germany >>> >>> Phone: +49 2461 61 2509 | +49 241 80 24381 >>> Fax: +49 2461 80 6 99753 >>> www.jara.org/jara-hpc >>> email: hermanns(a)jara.rwth-aachen.de >>> >>> >>> _______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >>> >> >> >> >> _______________________________________________ >> mpiwg-p2p mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> >> >> -- >> Dan Holmes >> Applications Consultant in HPC Research >> EPCC, The University of Edinburgh >> James Clerk Maxwell Building >> The Kings Buildings >> Peter Guthrie Tait Road >> Edinburgh >> EH9 3FD >> T: +44(0)131 651 3465 >> E: dholmes(a)epcc.ed.ac.uk >> >> *Please consider the environment before printing this email.* >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> > > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >

1 0

Info assertions draft
by Jim Dinan 09 Feb '16

09 Feb '16

Hi All, I have attached an updated draft for the info assertions proposal. The two week deadline is quickly approaching; please send feedback before the end of the week. Thanks, ~Jim.

1 0