October 2015 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Cancelling a send matched by a matching probe
by William Gropp 31 Oct '15

31 Oct '15

Under the interpretation of using whether the target process has observed, rather than received the message, a consistent interpretation is that the MPI_Cancel fails at the source, as it would if the message had been received. Its possible that the standard should require programs that have matched a message with Mprobe/Improbe to received the message before MPI_Finalize is called. However, the standard is out of date with respect to cancel of send, and should be updated (either to make this precise or to delete cancel of send). As Pavan has noted, there are a number of active proposals addressing this. Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science Chief Scientist, NCSA University of Illinois Urbana-Champaign On Oct 31, 2015, at 6:12 AM, Marek Tomáštík <tomastik.marek(a)gmail.com> wrote: > Hello, > I am trying to find out what should happen, according to the MPI 3.0* standard, in the following scenario: > 1) process 0 initiates a nonblocking send operation with MPI_Issend > 2) process 1 matches the message with MPI_Mprobe, but doesn't yet call MPI_Mrecv/MPI_Imrecv > 3) process 0 calls MPI_Cancel to cancel the send. > > I cannot think of anything the cancel operation could do that wouldn't contradict either the specification of MPI_Cancel, or of the matched receive functions. How can this situation be handled in compliance with the standard? > > Thank you in advance, > Marek Tomáštík > > > > *or 3.1 -- I believe there weren't any changes in this area? > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Cancelling a send matched by a matching probe
by Balaji, Pavan 31 Oct '15

31 Oct '15

This has been debated in the standard. There are a few tickets open for this issue. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 -- Pavan > On Oct 31, 2015, at 6:12 AM, Marek Tomáštík <tomastik.marek(a)gmail.com> wrote: > > Hello, > I am trying to find out what should happen, according to the MPI 3.0* standard, in the following scenario: > 1) process 0 initiates a nonblocking send operation with MPI_Issend > 2) process 1 matches the message with MPI_Mprobe, but doesn't yet call MPI_Mrecv/MPI_Imrecv > 3) process 0 calls MPI_Cancel to cancel the send. > > I cannot think of anything the cancel operation could do that wouldn't contradict either the specification of MPI_Cancel, or of the matched receive functions. How can this situation be handled in compliance with the standard? > > Thank you in advance, > Marek Tomáštík > > > > *or 3.1 -- I believe there weren't any changes in this area? > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Cancelling a send matched by a matching probe
by Marek Tomáštík 31 Oct '15

31 Oct '15

Hello, I am trying to find out what should happen, according to the MPI 3.0* standard, in the following scenario: 1) process 0 initiates a nonblocking send operation with MPI_Issend 2) process 1 matches the message with MPI_Mprobe, but doesn't yet call MPI_ Mrecv/MPI_Imrecv 3) process 0 calls MPI_Cancel to cancel the send. I cannot think of anything the cancel operation could do that wouldn't contradict either the specification of MPI_Cancel, or of the matched receive functions. How can this situation be handled in compliance with the standard? Thank you in advance, Marek Tomáštík *or 3.1 -- I believe there weren't any changes in this area?

1 0

Subscribing / Unsubscribing To GitHub Notifications
by Bland, Wesley 29 Oct '15

29 Oct '15

Those of you that have made the jump into GitHub from Trac may have noticed that you’re getting more email notifications than you used to. GitHub generally operates on the opt-out model for notifications where Trac was generally opt-in. Fear not! There are ways to customize this and keep your inbox quieter. I’ve written a new wiki page about it: https://github.com/mpi-forum/mpi-issues/wiki/Initial-GitHub-setup Take a look and make any changes you like. Thanks, Wesley

1 0

Github GitHub GITHUB!
by Jeff Squyres (jsquyres) 22 Oct '15

22 Oct '15

If you didn't read Wesley's detailed email (YOU SHOULD! ...but I know not everyone will :-( ), here's the executive summary: 1. Read Wesley's email: http://lists.mpi-forum.org/mpi-forum/2015/10/3112.php 2. Send Wesley/Jeff your Github ID. 3. Start moving any still-open Trac tickets to Github. 4. SVN is already read-only. Everything has been moved to Git repos on GitHub. 5. Trac goes read-only on Fri, 13 Nov 2015 6. Lots of good information is on our wiki: https://github.com/mpi-forum/mpi-issues/wiki - There's info for Git newbies - There's info for GitHub newbies - There's info about how the Forum uses GitHub 7. The Dec 2015 MPI Forum meeting will only accept Github Issue agenda items (not Trac tickets). 8. Read Wesley's email: http://lists.mpi-forum.org/mpi-forum/2015/10/3112.php -- 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: [Mpi-forum] MPI Forum SVN/Trac -> GitHub
by Bland, Wesley 22 Oct '15

22 Oct '15

Sorry, you’re right. We changed the name of that wiki page after I drafted the email. The correct link for the guide for creating issues is: https://github.com/mpi-forum/mpi-issues/wiki/How-to-file-an-MPI-Forum-issue… The links are correct within the wiki itself if all you’re doing is browsing around in there. On Oct 22, 2015, at 12:42 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: https://github.com/mpi-forum/mpi-issues/wiki/Issue-Workflow does not yet exist, and it's not because of a typo. I guess the content is there under some other name, but as written, the guidelines below are not 100% accurate. Jeff On Thu, Oct 22, 2015 at 8:58 AM, Bland, Wesley <wesley.bland(a)intel.com<mailto:[email protected]>> wrote: Hello Forum, The time has come to start moving things from Trac and Subversion to our new home on GitHub! If you missed the discussions at the last few MPI Forum meetings, we agreed that now was a good time to move to a new tool chain to modernize our revision control system to get the benefits offered by Git. As such, we're moving to GitHub to make working with the source code easier for working groups and individuals. For more history about why we decided to do this, take a look at the slides from the Bordeaux meeting (http://meetings.mpi-forum.org/secretary/2015/09/slides/MPI%20Forum%20SVN-Gi…) You can find our new home here: https://github.com/mpi-forum. Working groups also have their own homes (this is new!). To find links to the working group’s pages, look at the main wiki page: https://github.com/mpi-forum/mpi-issues/wiki. Especially note the rules for accessing the MPI Standard source code that you are implicitly agreeing to at the top of the wiki page. These are not restrictive and shouldn’t require anyone’s legal department to sign off on. There are lots of other guides in there that we’ve been putting together which should hopefully help both the Git wizard and novice. The timeline for this move is as follows: October 7, 2015: * SVN was made read-only. * The history of MPI 3.0 and 3.1 was moved into the new Git repository on GitHub. Older versions have less history preserved as it was lost in previous moves. Now: * Individuals should send your GitHub user IDs to Wesley and Jeff to be added to the main MPI Forum organization. * Individuals should *also* should send your user IDs to your working group chairs to get added to your working group’s organization. * Working Group chairs will be given control over their respective working group organizations, and should determine how they would like to use them *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Working-Group-Guidelines * Working Group chairs/members should start migrating any wiki pages that they would like to migrate to their respective working group’s repository. *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Migrating-Working-Group-wiki-p… * Trac ticket authors should start migrating tickets over to issues on the mpi-forum/mpi-issues repository (https://github.com/mpi-forum/mpi-issues) *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Migrating-old-Trac-tickets-to-… * Ticket authors should start writing text for their tickets and create pull requests with the proposed text to be reviewed by the MPI Forum. *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Issue-Workflow November 13, 2015: * Trac will be made read-only. * Working groups can no longer edit wiki pages. * Individuals can no longer edit or make comments on tickets. * Existing pages can still be viewed December 7, 2015: * First physical MPI Forum meeting using the new GitHub issues and pull request system. * Agenda items will only be accepted if they have a corresponding GitHub issue & pull request. Trac tickets are no longer allowed. If you have questions, feel free to contact Wesley or Jeff for more information. We know that this will be a little bit of work in the short term, but hopefully we can make this process as painless as possible and have a better set of tools in the future. To help with the transition, we’ll have a Webex on Monday, November 2nd at 11:00 AM Eastern US to give an overview on how things will work and the process for creating a ticket. For anyone who can’t join, we’ll record that Webex and post it to be viewed later. Information about the Webex: Webex URL: https://cisco.webex.com/ciscosales/j.php?MTID=m2b0cc8e68181a2288cec8658c3bb… Webex pw: nAmKMSEH Thanks, Wesley & Jeff _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI Forum SVN/Trac -> GitHub
by Jeff Hammond 22 Oct '15

22 Oct '15

https://github.com/mpi-forum/mpi-issues/wiki/Issue-Workflow does not yet exist, and it's not because of a typo. I guess the content is there under some other name, but as written, the guidelines below are not 100% accurate. Jeff On Thu, Oct 22, 2015 at 8:58 AM, Bland, Wesley <wesley.bland(a)intel.com> wrote: > Hello Forum, > > The time has come to start moving things from Trac and Subversion to our > new home on GitHub! > > If you missed the discussions at the last few MPI Forum meetings, we > agreed that now was a good time to move to a new tool chain to modernize > our revision control system to get the benefits offered by Git. As such, > we're moving to GitHub to make working with the source code easier for > working groups and individuals. For more history about why we decided to > do this, take a look at the slides from the Bordeaux meeting ( > http://meetings.mpi-forum.org/secretary/2015/09/slides/MPI%20Forum%20SVN-Gi… > ). > > You can find our new home here: https://github.com/mpi-forum. > > Working groups also have their own homes (this is new!). > > To find links to the working group’s pages, look at the main wiki page: > https://github.com/mpi-forum/mpi-issues/wiki. Especially note the rules > for accessing the MPI Standard source code that you are implicitly agreeing > to at the top of the wiki page. These are not restrictive and shouldn’t > require anyone’s legal department to sign off on. There are lots of other > guides in there that we’ve been putting together which should hopefully > help both the Git wizard and novice. > > The timeline for this move is as follows: > > October 7, 2015: > > * SVN was made read-only. > * The history of MPI 3.0 and 3.1 was moved into the new Git repository > on GitHub. Older versions have less history preserved as it was lost in > previous moves. > > Now: > > * Individuals should send your GitHub user IDs to Wesley and Jeff to be > added to the main MPI Forum organization. > * Individuals should *also* should send your user IDs to your working > group chairs to get added to your working group’s organization. > > * Working Group chairs will be given control over their respective > working group organizations, and should determine how they would like to > use them > *** Guidelines: > https://github.com/mpi-forum/mpi-issues/wiki/Working-Group-Guidelines > * Working Group chairs/members should start migrating any wiki pages > that they would like to migrate to their respective working group’s > repository. > *** Guidelines: > https://github.com/mpi-forum/mpi-issues/wiki/Migrating-Working-Group-wiki-p… > > * Trac ticket authors should start migrating tickets over to issues on > the mpi-forum/mpi-issues repository ( > https://github.com/mpi-forum/mpi-issues) > *** Guidelines: > https://github.com/mpi-forum/mpi-issues/wiki/Migrating-old-Trac-tickets-to-… > * Ticket authors should start writing text for their tickets and create > pull requests with the proposed text to be reviewed by the MPI Forum. > *** Guidelines: > https://github.com/mpi-forum/mpi-issues/wiki/Issue-Workflow > > November 13, 2015: > > * Trac will be made read-only. > * Working groups can no longer edit wiki pages. > * Individuals can no longer edit or make comments on tickets. > * Existing pages can still be viewed > > December 7, 2015: > > * First physical MPI Forum meeting using the new GitHub issues and pull > request system. > * Agenda items will only be accepted if they have a corresponding > GitHub issue & pull request. Trac tickets are no longer allowed. > > If you have questions, feel free to contact Wesley or Jeff for more > information. We know that this will be a little bit of work in the short > term, but hopefully we can make this process as painless as possible and > have a better set of tools in the future. > > To help with the transition, we’ll have a Webex on Monday, November 2nd at > 11:00 AM Eastern US to give an overview on how things will work and the > process for creating a ticket. For anyone who can’t join, we’ll record that > Webex and post it to be viewed later. > > Information about the Webex: > > Webex URL: > https://cisco.webex.com/ciscosales/j.php?MTID=m2b0cc8e68181a2288cec8658c3bb… > Webex pw: nAmKMSEH > > Thanks, > Wesley & Jeff > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

MPI Forum SVN/Trac -> GitHub
by Bland, Wesley 22 Oct '15

22 Oct '15

Hello Forum, The time has come to start moving things from Trac and Subversion to our new home on GitHub! If you missed the discussions at the last few MPI Forum meetings, we agreed that now was a good time to move to a new tool chain to modernize our revision control system to get the benefits offered by Git. As such, we're moving to GitHub to make working with the source code easier for working groups and individuals. For more history about why we decided to do this, take a look at the slides from the Bordeaux meeting (http://meetings.mpi-forum.org/secretary/2015/09/slides/MPI%20Forum%20SVN-Gi…) You can find our new home here: https://github.com/mpi-forum. Working groups also have their own homes (this is new!). To find links to the working group’s pages, look at the main wiki page: https://github.com/mpi-forum/mpi-issues/wiki. Especially note the rules for accessing the MPI Standard source code that you are implicitly agreeing to at the top of the wiki page. These are not restrictive and shouldn’t require anyone’s legal department to sign off on. There are lots of other guides in there that we’ve been putting together which should hopefully help both the Git wizard and novice. The timeline for this move is as follows: October 7, 2015: * SVN was made read-only. * The history of MPI 3.0 and 3.1 was moved into the new Git repository on GitHub. Older versions have less history preserved as it was lost in previous moves. Now: * Individuals should send your GitHub user IDs to Wesley and Jeff to be added to the main MPI Forum organization. * Individuals should *also* should send your user IDs to your working group chairs to get added to your working group’s organization. * Working Group chairs will be given control over their respective working group organizations, and should determine how they would like to use them *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Working-Group-Guidelines * Working Group chairs/members should start migrating any wiki pages that they would like to migrate to their respective working group’s repository. *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Migrating-Working-Group-wiki-p… * Trac ticket authors should start migrating tickets over to issues on the mpi-forum/mpi-issues repository (https://github.com/mpi-forum/mpi-issues) *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Migrating-old-Trac-tickets-to-… * Ticket authors should start writing text for their tickets and create pull requests with the proposed text to be reviewed by the MPI Forum. *** Guidelines: https://github.com/mpi-forum/mpi-issues/wiki/Issue-Workflow November 13, 2015: * Trac will be made read-only. * Working groups can no longer edit wiki pages. * Individuals can no longer edit or make comments on tickets. * Existing pages can still be viewed December 7, 2015: * First physical MPI Forum meeting using the new GitHub issues and pull request system. * Agenda items will only be accepted if they have a corresponding GitHub issue & pull request. Trac tickets are no longer allowed. If you have questions, feel free to contact Wesley or Jeff for more information. We know that this will be a little bit of work in the short term, but hopefully we can make this process as painless as possible and have a better set of tools in the future. To help with the transition, we’ll have a Webex on Monday, November 2nd at 11:00 AM Eastern US to give an overview on how things will work and the process for creating a ticket. For anyone who can’t join, we’ll record that Webex and post it to be viewed later. Information about the Webex: Webex URL: https://cisco.webex.com/ciscosales/j.php?MTID=m2b0cc8e68181a2288cec8658c3bb… Webex pw: nAmKMSEH Thanks, Wesley & Jeff

1 0

Re: [Mpi-forum] user-defined reductions and re-entrancy
by N.M. Maclaren 20 Oct '15

20 Oct '15

On Oct 20 2015, William Gropp wrote: >The standard doesn't explicitly address this. > > However, in the spirit of the standard, I would say yes, multiple threads > may be used. The behavior of side effects of the function are not > defined, nor is it required to apply to elements 0..n-1 in that order in > an n-element vector (this is a vector on each process; the is/is-not > commutative applies between processes). Rather than try to enumerate and > disallow certain actions, I think this is the right solution - the action > of the user function on the input parameters is defined; nothing else > should be. An implementation might warn users that the function may be > called by multiple threads concurrently (e.g., to use atomic memory > operations to count invocations or increment "evil"). While I agree in principle, that is disastrous in practice. None of C, Fortran nor POSIX are fit for such an implementation. I can see no sign that C11 is ever going to become established (even C99 took over a decade). Even if it did, its memory model is seriously and incomprehensibly ambiguous because (unlike C++11), it has left much of the old, ambiguous sequence point description in place. And (again unlike C11), it doesn't specify anything about any of the library macros and functions. Fortran doesn't say anything about threading. Its concept of purity is not enough, because there are two separate such concepts and it is the other that is really needed. I.e. a function call does not just not affect anything outside, but nothing outside affects it. It gets a long way there, but provides far too many loopholes. POSIX threading is a well-known disaster area, not least because it contains no description of how its rules relate to C's, because its list of thread-safe functions is quite simply broken, and because (God help us all) it says NOTHING about how to synchronise signalling and state control. And, yes, I have seen that produce logical impossibilities in the field, despite using some of its more heavyweight thread synchronisation. At the very least, it should be possible to ensure that any threading is transparent using MPI_Init_thread. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] user-defined reductions and re-entrancy
by Jeff Hammond 20 Oct '15

20 Oct '15

Thanks. I think this is a reasonable conclusion. One might expect an implementation that does this to expose control of internal concurrency by environment variables (or that fancy MPI_T business about which I know almost nothing) so as to ensure an "evil" user only blows their leg off once. Best, Jeff On Tue, Oct 20, 2015 at 11:19 AM, William Gropp <wgropp(a)illinois.edu> wrote: > The standard doesn’t explicitly address this. > > However, in the spirit of the standard, I would say yes, multiple threads > may be used. The behavior of side effects of the function are not defined, > nor is it required to apply to elements 0..n-1 in that order in an > n-element vector (this is a vector on each process; the is/is-not > commutative applies between processes). Rather than try to enumerate and > disallow certain actions, I think this is the right solution - the action > of the user function on the input parameters is defined; nothing else > should be. An implementation might warn users that the function may be > called by multiple threads concurrently (e.g., to use atomic memory > operations to count invocations or increment “evil”). > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > Chief Scientist, NCSA > University of Illinois Urbana-Champaign > > > > > > On Oct 20, 2015, at 1:04 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > Thanks Jed for clarifying. I agree with your modified example. > > > > The fundamental question here remains: can an implementation internally > call user-defined reduction operators from multiple threads at the same > time? > > > > Jeff > > > > Sent from my iPhone > > > >> On Oct 20, 2015, at 10:50 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> > >> "Balaji, Pavan" <balaji(a)anl.gov> writes: > >> > >>> You can't call MPI functions in there, but you can replace the abort > with an exit(1). > >> > >> MPI-3.0 p184: "MPI_ABORT may be called inside the function in case of > an error." > >> > >>> Each user function is called once per process, so "evil" will always > be 1, isn't it? I'm not sure why reentrance is an issue here. > >> > >> Jeff said "user code increments evil once between every call to this > >> function so that it should never fail in single-threaded execution". > >> > >> A self-contained rendition: > >> > >> void User_reduce(void* invec, void* inoutvec, int *len, MPI_Datatype > *datatype) > >> { > >> static int evil = 0; > >> double * in = (double*)invec; > >> double * out = (double*)inoutvec; > >> if (*datatype == MPI_DOUBLE && (++evil%2) == 1) { > >> for (int i=0; i<*len; i++) out[i] = evil*in[i]; > >> evil++; > >> } else { > >> MPI_Abort(1,MPI_COMM_WORLD); > >> } > >> } > >> > >> The results certainly depend on how an implementation segments a buffer > >> and on which process the reduction is called. Additionally, calling the > >> reduction from multiple threads may cause a non-deterministic abort. > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0