May 2017 - mpi-forum - mailman3.cels.anl.gov

Tools WG tickets for forum meeting
by Mohror, Kathryn 31 May '17

31 May '17

Hi all, The tools working group is announcing the following for the forum in June: - MPI_T reinitialization errata: #50: https://github.com/mpi-forum/mpi-issues/issues/50 o Reading and vote o Pull request: https://github.com/mpi-forum/mpi-standard/pull/25 - MPI_T error code deprecation: #60: https://github.com/mpi-forum/mpi-issues/issues/60 o Reading of change log and index changes * Last meeting we read the main ticket, and decided to come back with change log and index changes and have a 'no "no" vote' on these changes o If there are no objections to voting, then first vote o Pull request: https://github.com/mpi-forum/mpi-standard/pull/22 - MPIR line numbers: #6: https://github.com/mpi-forum/mpi-issues/issues/6 o Reading of MPIR side document with inclusion of line numbers Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Persistent Collective Communication Reading Request for June Meeting
by Anthony Skjellum 29 May '17

29 May '17

Please schedule a reading for issue #25 (pull request #29). https://github.com/mpi-forum/mpi-issues/issues/25 https://github.com/mpi-forum/mpi-standard/pull/29 ?Patch Links: * https://github.com/mpi-forum/mpi-standard/pull/29.patch * https://github.com/mpi-forum/mpi-standard/pull/29.diff ? ?Draft standard PDF, containing the changes to be read at next meeting: https://github.com/mpi-forum/mpi-standard/files/1036715/mpi32-report.pdf ?Summary of changes: Collective Communication Chapter ---------------------------------------------- 5.13 Added Persistent collective communication functions? 5.13.1 -- Added section to discuss Info Keys related to Persistent Collectibrs 5.13.2-5.13.13 -- Added one-to-one a persistent collective for every corresponding nonblocking collective Process Topologies chapter ------------------------------------ Added Section 7.8 -- Persistent collective communication for communication on process topologies; added one-to-one a function for every nonblocking topological collective operation For your information, we have a working functional implementation (libPNBC) as well. ?Thank you, Tony Skjellum, Puri Bangalore, and Dan Holmes

1 0

MPI Forum Meeting in Aachen / Logistics and Agenda
by Martin Schulz 29 May '17

29 May '17

Hi all, The MPI Forum meeting in Aachen is coming up quickly. As Marc-Andre already requested in his previous email, if you haven’t registered, yet, but are planning on attending, please do so as soon as possible. We need to get a good head count and understand the impact on the quorum. Here is the link to the logistics page: http://mpi-forum.org/meetings/2017/06/logistics <http://mpi-forum.org/meetings/2017/06/logistics> I have updated the agenda at: http://mpi-forum.org/meetings/2017/06/agenda <http://mpi-forum.org/meetings/2017/06/agenda> I think this captures all requests that I have gotten, but if I missed anything, please let me know as soon as possible. Also, I have listed all readings, votes, etc. that I am aware of and I am considering those scheduled. If there are any other items that need to be scheduled, please announce them before the 2 week deadline, which is Wednesday morning 9am German time. Thanks! Martin

1 0

Re: [Mpi-forum] Threading guarantees of MPI_User_function
by Jeff Hammond 29 May '17

29 May '17

It sounds like we need to add some text to the standard about this. At the very least, an advice to users about the thread context seems prudent. Can you add a ticket about this? Collectives WG seems like the right place... Jeff Sent from my iPhone > On May 29, 2017, at 9:18 AM, "Marc.PERACHE(a)CEA.FR" <Marc.PERACHE(a)CEA.FR> wrote: > > I’m sorry but the MPI_User_function is not always invoked by the thread that invokes the MPI function that uses it. When you have progression thread, the MPI_User_function may be called by this additional thread. > > Marc > > De : mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] De la part de William Gropp > Envoyé : vendredi 26 mai 2017 01:58 > À : Main MPI Forum mailing list > Objet : Re: [Mpi-forum] Threading guarantees of MPI_User_function > > Just to be clear on this, the MPI standard generally requires the user to enforce any synchronization needed when using threads with MPI, so Jeff’s answer is aligned with the standard. > > Bill > > William Gropp > Interim Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > On May 25, 2017, at 1:49 PM, Phil Ruffwind <rf(a)rufflewind.com> wrote: > > On Thu, May 25, 2017, at 12:55, Jeff Hammond wrote: > > I expect that MPI_User_function is invoked by the thread that invokes the > MPI function that uses it, and that you need a mutex to touch shared > state > associated with MPI_User_function when running with MPI_THREAD_MULTIPLE, > but not otherwise. > > I would hope that MPI implementations do not serialize calls to > MPI_User_function > in MPI_THREAD_MULTIPLE mode, because there are many cases where > MPI_User_function > is trivially reentrant and I would like simultaneous progress if I call > MPI_Allreduce concurrently from 2+ threads (with different communicators, > of course) with the same MPI_User_function. > > Thanks for clarifying. In that case, I'll assume synchronization is > necessary. > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Threading guarantees of MPI_User_function
by Marc.PERACHE＠CEA.FR 29 May '17

29 May '17

I’m sorry but the MPI_User_function is not always invoked by the thread that invokes the MPI function that uses it. When you have progression thread, the MPI_User_function may be called by this additional thread. Marc De : mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] De la part de William Gropp Envoyé : vendredi 26 mai 2017 01:58 À : Main MPI Forum mailing list Objet : Re: [Mpi-forum] Threading guarantees of MPI_User_function Just to be clear on this, the MPI standard generally requires the user to enforce any synchronization needed when using threads with MPI, so Jeff’s answer is aligned with the standard. Bill William Gropp Interim Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On May 25, 2017, at 1:49 PM, Phil Ruffwind <rf(a)rufflewind.com<mailto:[email protected]>> wrote: On Thu, May 25, 2017, at 12:55, Jeff Hammond wrote: I expect that MPI_User_function is invoked by the thread that invokes the MPI function that uses it, and that you need a mutex to touch shared state associated with MPI_User_function when running with MPI_THREAD_MULTIPLE, but not otherwise. I would hope that MPI implementations do not serialize calls to MPI_User_function in MPI_THREAD_MULTIPLE mode, because there are many cases where MPI_User_function is trivially reentrant and I would like simultaneous progress if I call MPI_Allreduce concurrently from 2+ threads (with different communicators, of course) with the same MPI_User_function. Thanks for clarifying. In that case, I'll assume synchronization is necessary. _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Registration for June Meeting in Aachen
by Marc-Andre Hermanns 29 May '17

29 May '17

Dear all, could everyone who already knows he or she will attend the June meeting and has not registered yet via [1], would please do so as soon as possible? Some people need an estimate on whether we reach quorum to justify travel, and it would be nice to give a close and up-to-date estimate for them. More info on the logistics side of the meeting can be found here: [2]. Thanks, Marc-Andre [1] https://www.zhv.rwth-aachen.de/kasse/catalog/product_info.php?cPath=37_67&p… [2] http://mpi-forum.org/meetings/2017/06/logistics -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich 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

MPI Forum Mailing Lists Online Again
by Bland, Wesley 26 May '17

26 May '17

The mailing list migration is complete and all of the lists should be online again. Thanks, Wesley

1 0

Re: [Mpi-forum] Threading guarantees of MPI_User_function
by William Gropp 25 May '17

25 May '17

Just to be clear on this, the MPI standard generally requires the user to enforce any synchronization needed when using threads with MPI, so Jeff’s answer is aligned with the standard. Bill William Gropp Interim Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On May 25, 2017, at 1:49 PM, Phil Ruffwind <rf(a)rufflewind.com> wrote: > > On Thu, May 25, 2017, at 12:55, Jeff Hammond wrote: >> I expect that MPI_User_function is invoked by the thread that invokes the >> MPI function that uses it, and that you need a mutex to touch shared >> state >> associated with MPI_User_function when running with MPI_THREAD_MULTIPLE, >> but not otherwise. >> >> I would hope that MPI implementations do not serialize calls to >> MPI_User_function >> in MPI_THREAD_MULTIPLE mode, because there are many cases where >> MPI_User_function >> is trivially reentrant and I would like simultaneous progress if I call >> MPI_Allreduce concurrently from 2+ threads (with different communicators, >> of course) with the same MPI_User_function. > > Thanks for clarifying. In that case, I'll assume synchronization is > necessary. > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Threading guarantees of MPI_User_function
by Phil Ruffwind 25 May '17

25 May '17

On Thu, May 25, 2017, at 12:55, Jeff Hammond wrote: > I expect that MPI_User_function is invoked by the thread that invokes the > MPI function that uses it, and that you need a mutex to touch shared > state > associated with MPI_User_function when running with MPI_THREAD_MULTIPLE, > but not otherwise. > > I would hope that MPI implementations do not serialize calls to > MPI_User_function > in MPI_THREAD_MULTIPLE mode, because there are many cases where > MPI_User_function > is trivially reentrant and I would like simultaneous progress if I call > MPI_Allreduce concurrently from 2+ threads (with different communicators, > of course) with the same MPI_User_function. Thanks for clarifying. In that case, I'll assume synchronization is necessary.

1 0

Re: [Mpi-forum] Threading guarantees of MPI_User_function
by Jeff Hammond 25 May '17

25 May '17

This is not necessary stated in the standard or guaranteed by it, it's just my intuition... I expect that MPI_User_function is invoked by the thread that invokes the MPI function that uses it, and that you need a mutex to touch shared state associated with MPI_User_function when running with MPI_THREAD_MULTIPLE, but not otherwise. I would hope that MPI implementations do not serialize calls to MPI_User_function in MPI_THREAD_MULTIPLE mode, because there are many cases where MPI_User_function is trivially reentrant and I would like simultaneous progress if I call MPI_Allreduce concurrently from 2+ threads (with different communicators, of course) with the same MPI_User_function. Jeff On Thu, May 25, 2017 at 9:35 AM, Phil Ruffwind <rf(a)rufflewind.com> wrote: > Hello all, > > I have another question about MPI_User_function. Does MPI make any > guarantees regarding (a) whether multiple invocations of > MPI_User_function could occur simultaneously within a given process for > a given MPI_Op, and regarding (b) which thread MPI_User_function gets > called on? > > The answer to (a) affects whether MPI_User_function would need any > synchronization (like mutexes or semaphores) if it mutates global state. > The answer to (b) affects whether it is possible to use thread-local > state inside MPI_User_function. > > I would appreciate any clarifications. Thanks. > Phil > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0