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

Re: [mpiwg-tools] Using MPI_T
by Junchao Zhang 24 Oct '13

24 Oct '13

Hi, Anh, I think your example is to use feedback to do throttling. A further question is: should we do it at application level (since you mentioned aggregation) or do it in MPI runtime? The example also implies processes need to communicate to know pressure of each other. Thanks. --Junchao Zhang On Thu, Oct 24, 2013 at 2:40 PM, Anh Vo <Anh.Vo(a)microsoft.com> wrote: > Hi Junchao,**** > > One example is monitoring the length of the unexpected message queues. > Basically, when an MPI process receives an incoming message from another > MPI process and it has not posted a receive for such message yet, the > message is typically copied into an unexpected receive queues. When the > process posts a receive, it loops through the unexpected queue and sees > whether any of the messages in the queue would match with this receive. If > the unexpected queue is too long, you would spend a lot of time looping > through the queue. Extra memcpy operations are also needed for unexpected > receive (vs the case where the message arrives and there’s already a posted > receive for it)**** > > ** ** > > By monitoring the length of the unexpected receive queue, the user can > adjust the rate of message flow. For example, if the other side processes > messages fast enough, you can keep sending lots of small data (such as > heart beat or piggyback), but in the case where the other side is slow > processing messages (thus end up with high queue depth for unexpected > queue), it might be more beneficial to compress the message or aggregate > them before sending**** > > ** ** > > --Anh**** > > ** ** > > *From:* mpiwg-tools [mailto:[email protected]] *On > Behalf Of *Junchao Zhang > *Sent:* Thursday, October 24, 2013 12:31 PM > *To:* <mpiwg-tools(a)lists.mpi-forum.org> > *Subject:* [mpiwg-tools] Using MPI_T**** > > ** ** > > Hello,**** > > The standard talks about the motivation of MPI_T as "MPI implementations > often use internal variables to control their operation and performance. > Understanding and manipulating these variables can provide a more efficient > execution environment or improve performance for many applications."**** > > I could imagine that through performance variables, users can know MPI > internal states during application execution. But how to use that to > improve performance? What EXTRA advantages does MPI_T bring? I don't get > the idea.**** > > Can someone shed light on that?**** > > Thank you.**** > > --Junchao Zhang**** > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] Using MPI_T
by Anh Vo 24 Oct '13

24 Oct '13

Hi Junchao, One example is monitoring the length of the unexpected message queues. Basically, when an MPI process receives an incoming message from another MPI process and it has not posted a receive for such message yet, the message is typically copied into an unexpected receive queues. When the process posts a receive, it loops through the unexpected queue and sees whether any of the messages in the queue would match with this receive. If the unexpected queue is too long, you would spend a lot of time looping through the queue. Extra memcpy operations are also needed for unexpected receive (vs the case where the message arrives and there's already a posted receive for it) By monitoring the length of the unexpected receive queue, the user can adjust the rate of message flow. For example, if the other side processes messages fast enough, you can keep sending lots of small data (such as heart beat or piggyback), but in the case where the other side is slow processing messages (thus end up with high queue depth for unexpected queue), it might be more beneficial to compress the message or aggregate them before sending --Anh From: mpiwg-tools [mailto:[email protected]] On Behalf Of Junchao Zhang Sent: Thursday, October 24, 2013 12:31 PM To: <mpiwg-tools(a)lists.mpi-forum.org> Subject: [mpiwg-tools] Using MPI_T Hello, The standard talks about the motivation of MPI_T as "MPI implementations often use internal variables to control their operation and performance. Understanding and manipulating these variables can provide a more efficient execution environment or improve performance for many applications." I could imagine that through performance variables, users can know MPI internal states during application execution. But how to use that to improve performance? What EXTRA advantages does MPI_T bring? I don't get the idea. Can someone shed light on that? Thank you. --Junchao Zhang

1 0

Using MPI_T
by Junchao Zhang 24 Oct '13

24 Oct '13

Hello, The standard talks about the motivation of MPI_T as "MPI implementations often use internal variables to control their operation and performance. Understanding and manipulating these variables can provide a more efficient execution environment or improve performance for many applications." I could imagine that through performance variables, users can know MPI internal states during application execution. But how to use that to improve performance? What EXTRA advantages does MPI_T bring? I don't get the idea. Can someone shed light on that? Thank you. --Junchao Zhang

1 0

Re: [mpiwg-tools] No call tomorrow
by Kathryn Mohror 18 Oct '13

18 Oct '13

Hi Jeff, > I am assuming that our friends in the US DOE labs are pretty hosed right now because of the tomfoolery going on with regards to the US budget situation. > > Let's therefore cancel tomorrow's call (unless Kathryn is able to reply and tell us otherwise!). Yes, we (at LLNL) were closed so I wasn't able to attend the call or send email regarding it. The good news is that we are open again now, so back to work! Thank you for taking the initiative to cancel the call. I'm hoping we'll have an extra-productive call next time to make up for it :-) Kathryn > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

No call tomorrow
by Jeff Squyres (jsquyres) 16 Oct '13

16 Oct '13

I am assuming that our friends in the US DOE labs are pretty hosed right now because of the tomfoolery going on with regards to the US budget situation. Let's therefore cancel tomorrow's call (unless Kathryn is able to reply and tell us otherwise!). -- 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: [mpiwg-tools] Questions on MPI_T_init_thread
by Schulz, Martin 14 Oct '13

14 Oct '13

Hi Junchao, On Oct 14, 2013, at 3:46 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hello, > I have some questions on MPI_T_init_thread, which are unclear in the Standard. > 1) Must MPI_T_init_thread() be called in programs before using MPI_T? Yes. > 2) Must MPI_T_init_thread() be only called by the main thread? No, I don't think we ever limited that (to allow tools running in other threads). > 3) Is it wrong to do > MPI_T_init_thread(MPI_THREAD_SINGLE, &provided); > MPI_Init_thread(LEVEL_HIGHER_THAN_SINGLE, &provided); > > or vice versa, > > MPI_Init_thread(MPI_THREAD_SINGLE, &provided); > MPI_T_init_thread(LEVEL_HIGHER_THAN_SINGLE, &provided); No, that should be OK - however, an MPI implementation can choose to return SINGLE from the second calls. Perhaps not the best implementation, but a correct one. Martin > > Thanks. > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Questions on MPI_T_init_thread
by Junchao Zhang 14 Oct '13

14 Oct '13

Hello, I have some questions on MPI_T_init_thread, which are unclear in the Standard. 1) Must MPI_T_init_thread() be called in programs before using MPI_T? 2) Must MPI_T_init_thread() be only called by the main thread? 3) Is it wrong to do MPI_T_init_thread(MPI_THREAD_SINGLE, &provided); MPI_Init_thread(LEVEL_HIGHER_THAN_SINGLE, &provided); or vice versa, MPI_Init_thread(MPI_THREAD_SINGLE, &provided); MPI_T_init_thread(LEVEL_HIGHER_THAN_SINGLE, &provided); Thanks. --Junchao Zhang

1 0

Re: [mpiwg-tools] Problem of MPI_T_PVAR_GET_INDEX
by Schulz, Martin 07 Oct '13

07 Oct '13

Hi Junchao, Great catch - thanks. We added the ability to have multiple variables with the same name but different classes on purpose to allow, e.g., a level, a high watermark, and a low watermark on the same resource. This still seems useful, so I don't think we should change that - adding the pvar class argument seems like the best (and also necessary) option. Martin On Oct 7, 2013, at 11:31 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > I noticed there is a proposal to query cvar/pvar/category index by their name. The one for pvar is questionable: > MPI_T_PVAR_GET_INDEX(name, pvar_index) > Since the Standard reads (p577) > > Advice to implementors. Groups of variables that belong closely together, but have different classes, can have the same name. This choice is useful, e.g., to refer to multiple variables that describe a single resource (like the level, the total size, as well as high and low watermarks). (End of advice to implementors.) > > It implies pvar names are not unique among pvar classes. So we need to require unique pvar names, or add a pvar class argument to MPI_T_PVAR_GET_INDEX. > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Problem of MPI_T_PVAR_GET_INDEX
by Junchao Zhang 07 Oct '13

07 Oct '13

I noticed there is a proposal to query cvar/pvar/category index by their name. The one for pvar is questionable: MPI_T_PVAR_GET_INDEX(name, pvar_index) Since the Standard reads (p577) * Advice to implementors.* Groups of variables that belong closely together, but have different classes, can have the same name. This choice is useful, e.g., to refer to multiple variables that describe a single resource (like the level, the total size, as well as high and low watermarks). (End of advice to implementors.) It implies pvar names are not unique among pvar classes. So we need to require unique pvar names, or add a pvar class argument to MPI_T_PVAR_GET_INDEX. --Junchao Zhang

1 0

Re: [mpiwg-tools] Working group meeting tomorrow!
by Kathryn Mohror 03 Oct '13

03 Oct '13

Hello, I put the notes from today's call on the wiki. As always, feel free to let me know if I missed something or got it wrong. https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2013-10-03 Kathryn On Oct 2, 2013, at 1:39 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > We'll have our regularly scheduled telecon tomorrow at 11AM EDT, 8AM PDT. As usual, the webex information is on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > Agenda: > - Discuss happenings at the forum > - We have tickets that may need discussion or work: > ticket 383 (make variable of same name have consistent meaning) > ticket 384 (dynamic strings ticket) > ticket 392 (return code for read/readreset on unstarted variable) (bill comment - adopt code/class error structure from the rest of MPI) > ticket 394 (clarification of values of watermark variables) > - Any other topics that people want to discuss. In particular, we may need to talk about picking up the debugger work again since we have been busy with MPI_T items lately. > > Kathryn > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0