From wade@cs.utk.edu Mon Jan 18 10:04:48 1993 Received: from THUD.CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA15560; Mon, 18 Jan 93 10:04:48 -0500 Received: from LOCALHOST.cs.utk.edu by thud.cs.utk.edu with SMTP (5.61++/2.7c-UTK) id AA03584; Mon, 18 Jan 93 10:04:42 -0500 Message-Id: <9301181504.AA03584@thud.cs.utk.edu> To: mpi-context-archive@surfer.EPM.ORNL.GOV Cc: wade@cs.utk.edu Subject: Date: Mon, 18 Jan 93 10:04:42 EST From: Reed Wade test From walker@rios2.epm.ornl.gov Mon Jan 18 13:23:40 1993 Received: from rios2.EPM.ORNL.GOV by surfer.EPM.ORNL.GOV (5.61/1.34) id AA19959; Mon, 18 Jan 93 13:23:40 -0500 Received: by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA17128; Mon, 18 Jan 1993 13:23:36 -0500 Date: Mon, 18 Jan 1993 13:23:36 -0500 From: walker@rios2.epm.ornl.gov (David Walker) Message-Id: <9301181823.AA17128@rios2.epm.ornl.gov> To: mpi-context-archive@surfer.EPM.ORNL.GOV From root Fri Jan 15 15:33:35 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA12164; Fri, 15 Jan 1993 15:33:34 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA07918; Fri, 15 Jan 93 15:33:30 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13121; Fri, 15 Jan 93 15:29:52 -0500 X-Resent-To: mpi-comm@CS.UTK.EDU ; Fri, 15 Jan 1993 15:29:51 EST Errors-To: owner-mpi-comm@CS.UTK.EDU Received: from rios2.EPM.ORNL.GOV by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13112; Fri, 15 Jan 93 15:29:50 -0500 Received: by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA13694; Fri, 15 Jan 1993 15:29:49 -0500 Date: Fri, 15 Jan 1993 15:29:49 -0500 From: walker@rios2.epm.ornl.gov (David Walker) Message-Id: <9301152029.AA13694@rios2.epm.ornl.gov> To: mpi-comm@cs.utk.edu Subject: Communication contexts Status: RO I thought the discussion of communication contexts at the last Dallas meeting was lacking in focus, and I'm afraid the existing subcommittees may not deal with this area. If there are enough people interested perhaps there should be a separate communication context subcommittee. If you have any strong opinions on this please let me know. Also let me know if you would like to be on the communication context subcommittee if one is established. On the topic of communication contexts I think (at least) 4 approaches have been proposed. 1) Implicit communication contexts as in MPI1 controlled by push/pop. 2) Explicit registration as in Zipcode 3) Explicit communication contexts should be merged with explicit group contexts. Since groups cannot communicate with each other a new communication context can be created by creating a new group with the same members as the current group. 4) Chuck Simmons of Oracle has suggested that communication contexts are really a particular type of thread, and so can be handled using existing threads packages. If you have any ideas, or are strongly for or against any of the above approaches let mpi-comm know so we can initiate a discussion of this topic. David Walker From root Fri Jan 15 15:47:37 1993 Received: from antares.mcs.anl.gov by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA16031; Fri, 15 Jan 1993 15:47:36 -0500 Received: from donner.mcs.anl.gov by antares.mcs.anl.gov (4.1/SMI-GAR) id AA03636; Fri, 15 Jan 93 14:47:35 CST Received: by donner.mcs.anl.gov (4.1/GCF-5.8) id AA00709; Fri, 15 Jan 93 14:47:32 CST Message-Id: <9301152047.AA00709@donner.mcs.anl.gov> To: mpi-comm@cs.utk.edu Subject: Communication contexts Cc: walker@rios2.epm.ornl.gov Date: Fri, 15 Jan 93 14:47:31 CST From: Rusty Lusk Status: RO | | On the topic of communication contexts I think (at least) 4 approaches have | been proposed. | 1) Implicit communication contexts as in MPI1 controlled by push/pop. | 2) Explicit registration as in Zipcode | 3) Explicit communication contexts should be merged with explicit | group contexts. Since groups cannot communicate with each other | a new communication context can be created by creating a new group | with the same members as the current group. | 4) Chuck Simmons of Oracle has suggested that communication contexts | are really a particular type of thread, and so can be handled | using existing threads packages. | If you have any ideas, or are strongly for or against any of the above | approaches let mpi-comm know so we can initiate a discussion of this topic. I think that 1) contradicts our genral agreement to avoid state as much as possible. 4) is a problem on systems that don't support threads, and we have more-or-less agreed to be consistent with thread packages but not depend upon them. 3) should be discussed along with the converse: that contexts rather than groups should be the primary concept and groups defined in terms of contexts. David, perhaps you could create a mailing list on which this discussion can take place, parallel to the subcommittee mailing lists, so it doesn't have to go to the whole committee. Thanks. Rusty From root Fri Jan 15 16:14:41 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA13265; Fri, 15 Jan 1993 16:14:39 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA08064; Fri, 15 Jan 93 16:14:35 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA16784; Fri, 15 Jan 93 16:12:04 -0500 X-Resent-To: mpi-comm@CS.UTK.EDU ; Fri, 15 Jan 1993 16:12:03 EST Errors-To: owner-mpi-comm@CS.UTK.EDU Received: from convex.convex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA16768; Fri, 15 Jan 93 16:12:01 -0500 Received: from mozart.convex.com by convex.convex.com (5.64/1.35) id AA21882; Fri, 15 Jan 93 15:11:54 -0600 Received: by mozart.convex.com (5.64/1.28) id AA01950; Fri, 15 Jan 93 15:11:17 -0600 Date: Fri, 15 Jan 93 15:11:17 -0600 From: weeks@mozart.convex.com (Dennis Weeks) Message-Id: <9301152111.AA01950@mozart.convex.com> To: mpi-comm@cs.utk.edu Subject: Communication contexts Cc: lusk@antares.mcs.anl.gov, walker@rios2.epm.ornl.gov Status: RO Rusty Lusk writes: > David, perhaps you could create a mailing list on which this discussion can > take place, parallel to the subcommittee mailing lists, so it doesn't have to > go to the whole committee. Thanks. I believe the default inclusion of everyone is a good idea, although creating a separate mailing list might be appropriate if some mpi-comm members wish to "unsubscribe". In the meantime, I will add one brief opinion: I felt that the discussions of contexts in the topology subgroup were quite sufficient, and it would probably be better to have the single subgroup which covers both groups and contexts, so that both will appear in the standard in a style which does not make them conflict with each other, and/or to avoid a proposal where groups and contexts would be totally redundant. I definitely agree that it is an important topic, and that the discussions last week in Dallas were far away from getting a proposal for groups and contexts that would be unanimously acceptable, so much work remains to be done. From root Fri Jan 15 17:03:11 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA13294; Fri, 15 Jan 1993 17:03:06 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA08266; Fri, 15 Jan 93 17:03:01 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21190; Fri, 15 Jan 93 17:00:57 -0500 X-Resent-To: mpi-comm@CS.UTK.EDU ; Fri, 15 Jan 1993 17:00:56 EST Errors-To: owner-mpi-comm@CS.UTK.EDU Received: from fslg8.fsl.noaa.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21182; Fri, 15 Jan 93 17:00:54 -0500 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA20492; Fri, 15 Jan 93 22:00:50 GMT Received: by macaw.fsl.noaa.gov (4.1/SMI-4.1) id AA14823; Fri, 15 Jan 93 14:59:49 MST Date: Fri, 15 Jan 93 14:59:49 MST From: hender@macaw.fsl.noaa.gov (Tom Henderson) Message-Id: <9301152159.AA14823@macaw.fsl.noaa.gov> To: mpi-comm@cs.utk.edu Subject: Re: Communication contexts Status: RO > | > | On the topic of communication contexts I think (at least) 4 approaches have > | been proposed. > | 1) Implicit communication contexts as in MPI1 controlled by push/pop. > | 2) Explicit registration as in Zipcode > | 3) Explicit communication contexts should be merged with explicit > | group contexts. Since groups cannot communicate with each other > | a new communication context can be created by creating a new group > | with the same members as the current group. > | 4) Chuck Simmons of Oracle has suggested that communication contexts > | are really a particular type of thread, and so can be handled > | using existing threads packages. > | If you have any ideas, or are strongly for or against any of the above > | approaches let mpi-comm know so we can initiate a discussion of this topic. > > I think that 1) contradicts our genral agreement to avoid state as much as > possible. 4) is a problem on systems that don't support threads, and we have > more-or-less agreed to be consistent with thread packages but not depend upon > them. 3) should be discussed along with the converse: that contexts rather > than groups should be the primary concept and groups defined in terms of > contexts. > > David, perhaps you could create a mailing list on which this discussion can > take place, parallel to the subcommittee mailing lists, so it doesn't have to > go to the whole committee. Thanks. > > Rusty I'm not sure, but I believe that Zipcode uses push/pop to control contexts (Tony, please correct me if I'm wrong). I'd like to add a 5th approach, basically the one proposed by Paul Pierce: 5) Contexts are used exclusively to insure that message collisions will not occur if independently developed sub-programs are combined. Contexts and groups are orthogonal. Contexts and threads are orthogonal. Each message has an associated context and tag. Message context is managed by library routines and is completely out of a user's control. Message tag is selected by the user. The method of managing message contexts is a separate issue (assuming we want contexts). Existing proposals are: 5a) Stack-based management (objected to due to hidden states). 5b) Explicit registration with user-defined "names" (probably requires some communication). 5c) Explicit registration by a central authority ("dollar bill" registration mentioned by Jim Cownie.) There is enough confusion about contexts and groups that we may want to keep this discussion open to everyone. If the concensus is to make a separate mailing list, please both of us to it. Thanks, Tom Henderson hender@fsl.noaa.gov Leslie Hart hart@fsl.noaa.gov From root Fri Jan 15 19:07:57 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA13061; Fri, 15 Jan 1993 19:07:55 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA08466; Fri, 15 Jan 93 19:07:50 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27214; Fri, 15 Jan 93 19:05:42 -0500 X-Resent-To: mpi-comm@CS.UTK.EDU ; Fri, 15 Jan 1993 19:05:41 EST Errors-To: owner-mpi-comm@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27206; Fri, 15 Jan 93 19:05:40 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA00450; Fri, 15 Jan 93 18:05:36 CST Date: Fri, 15 Jan 93 18:05:36 CST From: Tony Skjellum Message-Id: <9301160005.AA00450@Aurora.CS.MsState.Edu> To: hender@macaw.fsl.noaa.gov, mpi-comm@cs.utk.edu Subject: Re: Communication contexts Status: RO In Zipcode, contexts have a group-wide scope. Groups of processes can involve more than one context. For instance, if 10 processes are involved in several stages of a calculation, each stage might have a different notion of how to do messaging, but each would use all the processes. Groups are important, because they allow control over the scope of global operations. Contexts are important because they provide guarantees to sub-programs about restricted scope of messages. Contexts are added typing-like information, but which is controlled by the system, not ad hoc by each user program. When they determine to start messaging, sub-programs request a context from a "postmaster general" in Zipcode. Currently, this is a group-oriented request (loose synchronization) resulting in each group member getting the context, and other information. In a lower-level system, simpler tactics might be possible. The way we did it was supposed to avoid possibility of races or other problems like that. To build large-scale software, without globalization of the local use of messaging resources, and to provide scalable algorithms with efficient global operations, both groups and contexts are needed. The push/pop state is an implementation detail of little importance. -Tony From root Sat Jan 16 02:08:07 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA15898; Sat, 16 Jan 1993 02:08:06 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA09478; Sat, 16 Jan 93 02:08:01 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11696; Sat, 16 Jan 93 02:06:16 -0500 X-Resent-To: mpi-comm@CS.UTK.EDU ; Sat, 16 Jan 1993 02:06:15 EST Errors-To: owner-mpi-comm@CS.UTK.EDU Received: from sol.cs.wmich.edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11688; Sat, 16 Jan 93 02:06:13 -0500 Received: from id.wmich.edu (id.cs.wmich.edu) by cs.wmich.edu (4.1/SMI-4.1) id AA06036; Sat, 16 Jan 93 02:01:08 EST Date: Sat, 16 Jan 93 02:01:08 EST From: john@cs.wmich.edu (John Kapenga) Message-Id: <9301160701.AA06036@cs.wmich.edu> To: mpi-comm@cs.utk.edu Status: RO hi; It was my feeling that the concepts of group and context, that were clearly understood differently by different people at the start of the discussions, became somewhat better agreed on as the pt2pt discussion took place. Groups - used to define groups of processors for collective communication primitives and to allow mapping topologies onto processors. This allows a group of processors to be used in isolation to compute together. Contexts - As Tom (and Tony) express below, > From: hender@macaw.fsl.noaa.gov (Tom Henderson) > Message-Id: <9301152159.AA14823@macaw.fsl.noaa.gov> > To: mpi-comm@cs.utk.edu > Subject: Re: Communication contexts > Status: R > > I'd like to add a 5th approach, basically the one proposed by Paul Pierce: > > 5) Contexts are used exclusively to insure that message collisions will not > occur if independently developed sub-programs are combined. Contexts and > groups are orthogonal. Contexts and threads are orthogonal. Each message > has an associated context and tag. Message context is managed by library > routines and is completely out of a user's control. Message tag is > selected by the user. The only expression stated so far about the difference between tags and contexts I had gleaned was that context should now be wildcardable (IE no -1 for All contexts) while a receive ALL or some other MASK variant would be allowed on tags. > > The method of managing message contexts is a separate issue (assuming we > want contexts). Existing proposals are: > > 5a) Stack-based management (objected to due to hidden states). > 5b) Explicit registration with user-defined "names" (probably requires > some communication). > 5c) Explicit registration by a central authority ("dollar bill" > registration mentioned by Jim Cownie.) Add: 5d) A context is not strictly managed, but use should follow suggested guidelines. This could allow static allocation of contexts when reasonable, but also support a context server (as the Postmaster General in Zipcode). Think of the static contexts or non-registrar provided contexts as reserved with respect to any registration system. This could be part of the MPI initialization call, if a registrar is included. The drawback here of course is the user could violate whatever guidelines were given. It seems to me most types of name registration or stack allocation schemes, that are not too restrictive and allows user code to interact, are likely to allow errant management of contexts as well. I expect that allowing 5d) would let strictly controlled context systems to be built over MPI. > From: Tony Skjellum > Message-Id: <9301160005.AA00450@Aurora.CS.MsState.Edu> > To: hender@macaw.fsl.noaa.gov, mpi-comm@cs.utk.edu > Subject: Re: Communication contexts > Status: R > > In Zipcode, contexts have a group-wide scope. Groups of processes can Of course if we eliminate groups from the pt2pt call then contexts may not be explicitly limited to groups in MPI. (though a context server could be asked to provide a context relative to a group). > involve more than one context. For instance, if 10 processes are involved > in several stages of a calculation, each stage might have a different notion > of how to do messaging, but each would use all the processes. Groups > are important, because they allow control over the scope of global operations. > Contexts are important because they provide guarantees to sub-programs > about restricted scope of messages. Contexts are added typing-like > information, but which is controlled by the system, not ad hoc by each > user program. When they determine to start messaging, sub-programs > request a context from a "postmaster general" in Zipcode. Currently, this ... > To build large-scale software, without globalization of the local use of > messaging resources, and to provide scalable algorithms with efficient > global operations, both groups and contexts are needed. The push/pop > state is an implementation detail of little importance. I expect the use push/pop for context state would make implementation in some environments hard and I have some concern about requiring registration on very large systems. I do think a strictly controlled stack context system could be built over 5d). The question about context management relates to how high a level MPI should be at. I see it at a low level, that higher level systems can be built on. That is one reason for keeping context management "advisory". > > -Tony > I liked the zipcode documentation. I think it would be a good idea to make it available on netlib. john From root Sat Jan 16 06:08:50 1993 Received: from msr.EPM.ORNL.GOV by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA13121; Sat, 16 Jan 1993 06:08:44 -0500 Received: from CS.UTK.EDU by msr.epm.ornl.gov (5.67/1.34) id AA09829; Sat, 16 Jan 93 06:07:24 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00620; Sat, 16 Jan 93 06:03:55 -0500 X-Resent-To: mpi-pt2pt@CS.UTK.EDU ; Sat, 16 Jan 1993 06:03:46 EST Errors-To: owner-mpi-pt2pt@CS.UTK.EDU Received: from gatekeeper.oracle.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00612; Sat, 16 Jan 93 06:03:37 -0500 Received: from jewel.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA21711; Sat, 16 Jan 93 03:03:35 PST Received: by jewel.us.oracle.com (5.59.10/37.3) id AA01231; Sat, 16 Jan 93 03:08:56 PST Message-Id: <9301161108.AA01231@jewel.us.oracle.com> Date: Sat, 16 Jan 93 03:08:56 PST From: Charles Simmons To: mpi-pt2pt@cs.utk.edu Subject: RE: Communication contexts Status: RO > | 4) Chuck Simmons of Oracle has suggested that communication contexts > | are really a particular type of thread, and so can be handled > | using existing threads packages. > possible. 4) is a problem on systems that don't support threads, and we have > more-or-less agreed to be consistent with thread packages but not depend upon > them. 3) should be discussed along with the converse: that contexts rather Allow me to clarify my sentiments. The example of context usage given in the MPI draft documentation appears to explicitly assume the existance of threads, and here contexts appear to be being used as threads. > 5) Contexts are used exclusively to insure that message collisions will not > occur if independently developed sub-programs are combined. Contexts and > groups are orthogonal. Contexts and threads are orthogonal. Each message > has an associated context and tag. Message context is managed by library > routines and is completely out of a user's control. Message tag is > selected by the user. I could strongly support almost all of the above. [The part I wouldn't support is a "tag" as I will explain below.] We do our work on the nCUBE, which, as you may know, has a message passing interface essentially equivalent to that proposed by MPI. We ran into the exact problem quoted above: it was difficult to write libraries that we're guaranteed not to conflict in their usage of message types. The usage of the word "contexts" in the above is equivalent to the usage of the word "ports" amongst operating systems programmers. Because "port" is slightly less overloaded than "context", I prefer the word "port". Note that ports are sufficiently powerful that they subsume the concepts of "contexts", "pids", and "message types" or "tags" as used by MPI. >The only expression stated so far about the difference between tags and >contexts I had gleaned was that context should now be wildcardable (IE no >-1 for All contexts) while a receive ALL or some other MASK variant would >be allowed on tags. I agree that there is little difference between tags and contexts. This helps explain why ports are so good at subsuming both contexts and tags. > The method of managing message contexts is a separate issue (assuming we > want contexts). Existing proposals are: > > 5a) Stack-based management (objected to due to hidden states). > 5b) Explicit registration with user-defined "names" (probably requires > some communication). > 5c) Explicit registration by a central authority ("dollar bill" > registration mentioned by Jim Cownie.) I don't particularly understand the above, probably because I haven't been listening in on enough of the discussion. I think I understand what you mean by stack-based management, and we do use the word "registration"... When using ports, stack-based management isn't an issue for the same reasons you don't manage pids and message types using stack based management. For example, when sending a message, instead of using the MPI push_context (contextp); send (dest, type, buf, buflen); pop_context (contextp); you use send (port, buf, buflen); In our usage, a "port" is simply a queue to which messages can be sent. The receiver can remove a message from the head of the queue. Wildcards are neither needed nor implemented, making ports more efficient. The efficiency arises from the fact that a process can have multiple ports. In MPI, you essentially implement one receive queue for each pid. If you want to use a wildcard to access messages out-of-order, you need to waste time scanning the queue. With multiple ports, however, you can set up multiple queues so that you never need to access anything other than the head of a queue. Sometimes ports do need to be "registered". In our terminology, registration is the process of publishing in a well-known location sufficient information about a "port" created by one process that another process can send messages to that port. This is a very high level action that is almost outside the scope of MPI. We use a nameserver for this purpose. (The nameserver is accessed via a well-known port, i.e. a port whose bit-pattern is a well-known constant.) [Do note that we require that the bit-pattern representing a port be allowed to be transmitted between to processes without the operating system needing to know that the bit-pattern represents a port. This means that accessing the nameserver is not required in order to use a port.] For groups, we have thought about extending the concept of a port to an array-port. The simple implementation of this allows each process in a group to create a port. These ports are all sent to a central location which creates an array of ports and broadcasts the array to all ports in the array. The complex memory efficient implementation may require processes of a group to be created in a special fashion. Basically, it allows the address of a port for a specific process in a group to be easily computed by another process given the port of the first process in the group and the index of the target process in the group. -- Chuck From owner-mpi-context@CS.UTK.EDU Tue Jan 19 08:54:15 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA14013; Tue, 19 Jan 93 08:54:15 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13129; Tue, 19 Jan 93 08:53:41 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 19 Jan 1993 08:53:40 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from rios2.EPM.ORNL.GOV by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA13121; Tue, 19 Jan 93 08:53:39 -0500 Received: by rios2.epm.ornl.gov (AIX 3.2/UCB 5.64/4.03) id AA16410; Tue, 19 Jan 1993 08:53:38 -0500 Date: Tue, 19 Jan 1993 08:53:38 -0500 From: walker@rios2.epm.ornl.gov (David Walker) Message-Id: <9301191353.AA16410@rios2.epm.ornl.gov> To: mpi-context@cs.utk.edu Subject: Chair Tony Skjellum of Mississippi State University has kindly agreed to chair the MPI subcommittee on contexts. Regards, David From owner-mpi-context@CS.UTK.EDU Tue Jan 19 11:37:59 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA17976; Tue, 19 Jan 93 11:37:59 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21893; Tue, 19 Jan 93 11:37:36 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 19 Jan 1993 11:37:30 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from marge.meiko.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21879; Tue, 19 Jan 93 11:37:21 -0500 Received: from hub.meiko.co.uk by marge.meiko.com with SMTP id AA13277 (5.65c/IDA-1.4.4); Tue, 19 Jan 1993 11:36:49 -0500 Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk (4.1/SMI-4.1) id AA27411; Tue, 19 Jan 93 16:36:38 GMT Date: Tue, 19 Jan 93 16:36:37 GMT From: jim@meiko.co.uk (James Cownie) Message-Id: <9301191636.AA27411@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA05440; Tue, 19 Jan 93 16:35:18 GMT To: csimmons@us.oracle.com Cc: mpi-pt2pt@cs.utk.edu, mpi-context@cs.utk.edu In-Reply-To: Charles Simmons's message of Sat, 16 Jan 93 02:21:14 PST <9301161021.AA01226@jewel.us.oracle.com> Subject: mpi Content-Length: 3447 To: mpi-pt2pt@meiko.co.uk, mpi-context.@meiko.co.uk (Apologies to those who get it twice) Gentlepeople, Chuck Simmons has raised some interesting issues, with which I have a great deal of sympathy. The original messaging model which we implemented on our machines (and which we still support, and expect to continue to support) is in exactly the vein which Chuck is asking for (and has been used for an Oracle port !). In particular CSN supports 1) multiple end points for communication in a single process (know as "transports") 2) No tagging of messages 3) No system buffering, but the ability for users to queue multiple non-blocking receives on a transport, thus providing the buffering they require. 4) Send and receive by struct iovec. (As Chuck observes, the implementation ends up building an iovec (on the stack) for the simpler forms) 5) Both blocking and non-blocking tests for I/O completion. (our test actually has a timeout value). 6) The ability to pass transport addresses around the machine without the system being involved. 7) A standard name server service to associate textual names with transport addresses. If people are really interested then I can probably send the man pages. (Though this is not the main point of this note). HOWEVER (and this is one of the points) although this system had clean, specified semantics and a fast implementation (on our hardware), it hasn't helped to sell machines, and we have now produced an NX style interface as an alternative. I think that the problem with popularising such an interface among users is that it appears to do less for them than a model with implicit buffering, and is therefore harder to start to use. The fact that it allows them greater control and can ultimately produce higher performance is not their immediate concern and does not therefore count for much. Many FORTRAN programmers in particular to do not wish to be concerned with "system programming issues" like buffer management. I would certainly like MPI to be able to support such an interface (so that we can achieve the higher performance it offers, and also make MPI applicable in non-scientific application areas). (Though those who were present in Dallas will have noted that I wasn't trying to push such an approach there, mainly because I think it's a lost cause. NX style is what we have to live with...) (Second point coming up...) However it crosses my mind that there may be some potential for embedding such an interface within the MPI model. (This is a vague thought, but I'm throwing it out so others can think about it as well). Observe that 1) Marc's persistent communication descriptors seem to remove the tag matching requirement (though they're still rather vague !) 2) One way of viewing contexts would be to implement a context as a particular queue of messages (or in other words an entirely separate communication end point) within a process. (The implications of this for contexts would be a) contexts must be declared before use b) their number may be limited c) they should be freed after use ) The combination of the two things could then come somewhere near to what Chuck is asking for... -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 FAX : +44 454 618188 E-Mail: jim@meiko.co.uk or jim@meiko.com From owner-mpi-context@CS.UTK.EDU Tue Feb 2 11:00:00 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA21520; Tue, 2 Feb 93 11:00:00 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22663; Tue, 2 Feb 93 10:59:18 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 10:59:17 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from marge.meiko.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22655; Tue, 2 Feb 93 10:59:11 -0500 Received: from hub.meiko.co.uk by marge.meiko.com with SMTP id AA28603 (5.65c/IDA-1.4.4 for ); Tue, 2 Feb 1993 10:59:07 -0500 Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk (4.1/SMI-4.1) id AA22488; Tue, 2 Feb 93 15:58:57 GMT Date: Tue, 2 Feb 93 15:58:57 GMT From: jim@meiko.co.uk (James Cownie) Message-Id: <9302021558.AA22488@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA03309; Tue, 2 Feb 93 15:57:21 GMT To: mpi-context@cs.utk.edu Subject: Restricted contexts Content-Length: 6135 A view on contexts ================== At the last meeting in Dallas there was a strong feeling that some form of "context" was required in MPI. The major reason for this is the desire to separate communications on behalf of (independently compiled) library routines from those performed by the user's application. The use of specific message tags for this is discounted because it would require tag registration both by the library and the user code. This intrusion into the user's constitutional right to use whatever tags she sees fit is viewed as unacceptable, hence the requirement to add what is essentially just another tag field. [Of course here in Britain we don't have a written constitution, and the government just does what it likes...] In fact adding a further tag field (called context) does not remove the registration requirement, though it does mean that registration is only required by library routines. (In effect a default context is reserved by the allocator for the user, and she need not concern herself about it.) I should like to propose a different view of what a context is. Suppose we think of each context as a separate communications end point in the process (and intend to implement it this way too !). This has various implications :-- 1) A context should be created before it can be used. (This has the effect of allocating a new message queue inside the MPI implementation). 2) The number of contexts will be limited (you might expect < 256) [ I don't see this as a problem, after all you still have all of the tags available in each context, and how many nested libraries do you expect to use ? ] 3) A context should be deleted when use of it is complete. (So that the system can release the queue. This also gives a good point at which to report errors such as unreceived messages still on the queue). 4) Creation of a context can be a local operation. (Since the context is probably just an index into a local table. cf. unix file descriptors) [Though this may not be true when collective operations filtered by context are taking place, in this case one will want the same context in all members of the collective group, perhaps some contexts need to be reserved for allocation in group.] 5) Context values can be passed in messages without needing translation or registration. (This is important for maintaining scalability. The context information need only be passed to those processes which require it. [Though there's an unaddressed bootstrap problem here...]) 6) It is still possible to have a context lookup/allocation scheme if necessary. 7) It is possible for the user to avoid most of the tag matching cost (as has been requested by Chuck Simmons), all she (the user, not Chuck!) has to do is allocate contexts and target messages at them. Within a particular context all receives can have tag MATCH_ANY, and no queue searching is required. Since the context selection is fast (because we have restricted the number of contexts so that it is sensible to implement the selection as an array access) this improves the achieved performance. Given this style, then the implementation is extremely easy (and will be fast). One simply has an array of message lists, the context number being the index into the array. All of the operations (such as tag matching) can then use the existing code. This will (in general) produce an implemetation which runs faster than having a single queue of messages and matching on both tag and context, since the message queues will be shorter, and only contain relevant buffers. [Contrast with the case of additional code to match contexts on one message list which would slow down all code, whether or not contexts are being used !] The model of communication is that the context is a part of the TARGET address, both for collective and diadic communications. In effect the end point for communication is only relevant at the receiver. [Is this what we want ? The only place it seems to make a difference is in the tests for completion of non-blocking sends. If the user has queued many of these on the single outgoing queue, then when the library is searching for completed ones it has to skip them. If we have many outgoing queues this is not necessary. It rather depends on the way we test for completion of non-blocking sends, which has yet to be determined...] Functions might look like typedef ... MPI_CONTEXT; MPI_CONTEXT MPI_NEWCONTEXT(MPI_GROUP group); Allocate a new context for use within the given group (may be MPI_NO_GROUP, in which case the allocation is entirely local). Returns MPI_NO_CONTEXTS if there are no suitable free contexts left. If the group is not MPI_NO_GROUP, then this is a barrier synchronisation of all the processes in the group, and the result of the function is the same in all of the participating processes. int MPI_FREECONTEXT(const MPI_CONTEXT context); Free the given context, returns MPI_SUCCESS if the context has been freed MPI_NOTCONTEXT if the context is not valid MPI_BUSY if the context still has outstanding messages (I'm not sure if we need this last one, but the model of unix file descriptors suggests it might be useful...) int MPI_MOVECONTEXT(const MPI_CONTEXT to, const MPI_CONTEXT from); Rename the context from to be the context to. (cf dup2). This is a simple renaming operation. MPI_SUCCESS if the context has been renamed MPI_NOTCONTEXT if the from context is not valid MPI_BUSY if the to context is already allocated One of the arguments to the send routines (both diadic and collective) would then be an MPI_CONTEXT to which the message will be sent. Feedback please. Although this is a long message I'm not offering beer. [The pound is now down to $1.45 and still falling !] -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From owner-mpi-context@CS.UTK.EDU Tue Feb 2 11:49:30 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA22912; Tue, 2 Feb 93 11:49:30 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA24957; Tue, 2 Feb 93 11:49:03 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 11:49:02 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from fslg8.fsl.noaa.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA24949; Tue, 2 Feb 93 11:48:58 -0500 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA28146; Tue, 2 Feb 93 16:48:54 GMT Received: by macaw.fsl.noaa.gov (4.1/SMI-4.1) id AA01526; Tue, 2 Feb 93 09:47:49 MST Date: Tue, 2 Feb 93 09:47:49 MST From: hender@macaw.fsl.noaa.gov (Tom Henderson) Message-Id: <9302021647.AA01526@macaw.fsl.noaa.gov> To: mpi-context@cs.utk.edu Subject: Re: Restricted contexts A few (probably dumb) questions about Jim's context proposal: > MPI_CONTEXT MPI_NEWCONTEXT(MPI_GROUP group); > Allocate a new context for use within the given group (may be > MPI_NO_GROUP, in which case the allocation is entirely local). Returns ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > MPI_NO_CONTEXTS if there are no suitable free contexts left. > If the group is not MPI_NO_GROUP, then this is a barrier > synchronisation of all the processes in the group, and the result of > the function is the same in all of the participating processes. In what situations would I want a context that is entirely local? Would I need to send this context to a process I intend to communicate with? I like the idea of being able to create a context within a group for scalability reasons. How do I know that two groups will not get the "same" new context returned from separate calls to MPI_NEWCONTEXT()? Is this even a problem? > One of the arguments to the send routines (both diadic and collective) > would then be an MPI_CONTEXT to which the message will be sent. Does this mean that MPI_CONTEXT is NOT a required argument to a receive routine? (Maybe I'm missing the whole point of this proposal! If so, please educate me. A pseudo-code examle might be very helpful.) > Although this is a long message I'm not offering beer. [The pound is > now down to $1.45 and still falling !] This whole beer thing is getting pretty scary. I think I'll keep all my messages short! :) Tom Henderson hender@fsl.noaa.gov From owner-mpi-context@CS.UTK.EDU Tue Feb 2 12:15:44 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA23454; Tue, 2 Feb 93 12:15:44 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26210; Tue, 2 Feb 93 12:15:20 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 12:15:18 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA26192; Tue, 2 Feb 93 12:15:16 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA03830; Tue, 2 Feb 93 11:14:40 CST Date: Tue, 2 Feb 93 11:14:40 CST From: Tony Skjellum Message-Id: <9302021714.AA03830@Aurora.CS.MsState.Edu> To: mpi-context@cs.utk.edu, jim@meiko.co.uk Subject: Re: Restricted contexts Ladies/Gentlemen: The notion of context implementation for efficiency should not drive it to be a highly limited field. It is true than if there are only a few contexts, then they could be moved to hardware support. I think that large software will have many hundreds of contexts, and that this resource should be less limited. I dislike the notion that hardware-specific details creep into the standard. For instance, CM-5 could/does have 8 hardware contexts of messages, at a low level, but these are not really published to the user at all. The issue of whether one or many queues are supported is completely separate, and can be addressed separately. Separate queues weaken the partial ordering guaranteee of a message passing system; ie, that messages are received in pairwise-preserved order. Hence, they have been avoided thus far in the work I have done. However, there is nothing in principle wrong with letting an implementation disperse messages as they come in based on context. The best partial screening for messages is highly application dependent. Perhaps some type of adaptive hashing could be used internal to strong implementations, but it should not be required. For instance, independent of context support totally, adaptive hashing on type/sender could be incorporated to existing systems. I do not think it too inefficient to test 64 bits instead of 32 bits for typing. In practice, there are much more serious overheads in a system. The notion that we have full push-down message stacks, is an example of this. Active messages systems are highly context oriented. They make the context bigger (eg, an address on the destination machine) rather than smaller. One can see that there is a basic unity between message selection and context support... contexts help to route messages to the right execution part of a destination process. Registry is very important, because it guarantees that code (be it user or other library code) will cooperate reasonably well, given the message resource. This type of registry is accepted for file systems, for instance, where we accept that FORTRAN unit number is a bad way to program. Unix file descriptors provide insulation between different parts of a program. Same idea for contexts. Is a context associated with a group? Well, I hope so, but enforcing this is less important. Groups are very important in and of themselves, and to have guarantee that a context is available in a group is very useful. It also makes sense to me that a loosely synchronous registry by a group of processes to get a context is a good idea. For instance, a big group of processes initially has a context. It can ask for more contexts, and pinch off subgroups, establishing an MPMD processing environment. Overlap is permitted. Smaller groups of processes, starting with their own contexts would need a way to union into bigger groups. A mechanism for this is needed. This direction is important for scalability, for fault tolerance, and for dynamicism in processing on large collections of distributed or parallel processors. For instance, homogeneous clusters could union into a heterogeneous collection, and the resulting communication structure would provide a tree-like (at least two-level) access to messaging, which could also be useful for optimizing performance of global communication in a heterogeneous setting. Other ideas? - Tony Skjellum From owner-mpi-context@CS.UTK.EDU Tue Feb 2 12:52:23 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA24044; Tue, 2 Feb 93 12:52:23 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27903; Tue, 2 Feb 93 12:51:29 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 12:51:28 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from marge.meiko.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27887; Tue, 2 Feb 93 12:51:22 -0500 Received: from hub.meiko.co.uk by marge.meiko.com with SMTP id AA00407 (5.65c/IDA-1.4.4 for ); Tue, 2 Feb 1993 12:51:19 -0500 Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk (4.1/SMI-4.1) id AA22983; Tue, 2 Feb 93 17:51:16 GMT Date: Tue, 2 Feb 93 17:51:15 GMT From: jim@meiko.co.uk (James Cownie) Message-Id: <9302021751.AA22983@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA03315; Tue, 2 Feb 93 17:49:35 GMT To: hender@macaw.fsl.noaa.gov Cc: mpi-context@cs.utk.edu In-Reply-To: Tom Henderson's message of Tue, 2 Feb 93 09:47:49 MST <9302021647.AA01526@macaw.fsl.noaa.gov> Subject: Restricted contexts Content-Length: 2607 > A few (probably dumb) questions about Jim's context proposal: Not dumb. > In what situations would I want a context that is entirely local? Would I > need to send this context to a process I intend to communicate with? The basic model I have is that contexts are very similar to Unix file descriptors (maybe I should have said this more explicitly). Therefore you can create them locally, however if someone is going to send a message to one of your contexts the they need to know its identity. So the answer to the second question is YES, you'll have to send it to them [hence the bootstrap problem...]. > I like the idea of being able to create a context within a group for > scalability reasons. How do I know that two groups will not get the "same" > new context returned from separate calls to MPI_NEWCONTEXT()? Is this even > a problem? Since contexts are allocated within a group and context creation is a barrier synchronisation there are two cases to consider :- 1) the two groups creating contexts are disjoint. In this case the contexts are independently created, and may indeed be given the same number. (Just as opening files in two processes can return the same file descriptor). I don't think this is a problem. 2) The two groups share some members. In this case we only have a problem if we have threads (since otherwise a single thread needs to be at two barriers simultaneously, which it can't.) If we do have threads, then there will have to be a lock in the library to ensure that different results are given to the two groups. > > One of the arguments to the send routines (both diadic and collective) > > would then be an MPI_CONTEXT to which the message will be sent. > > Does this mean that MPI_CONTEXT is NOT a required argument to a receive > routine? (Maybe I'm missing the whole point of this proposal! If so, please > educate me. A pseudo-code examle might be very helpful.) No you do need a context in the receive (though it might be optional in the "simple" versions with some specific default value). The issue I was addressing was whether a send needed to specify one context (that at the target), or two (that at the target and that at the sender). I was tending towards the former solution. I'll try to write some examples tomorrow. -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From owner-mpi-context@CS.UTK.EDU Tue Feb 2 13:12:02 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA24463; Tue, 2 Feb 93 13:12:02 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28864; Tue, 2 Feb 93 13:10:58 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 13:10:56 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from marge.meiko.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28850; Tue, 2 Feb 93 13:10:51 -0500 Received: from hub.meiko.co.uk by marge.meiko.com with SMTP id AA00681 (5.65c/IDA-1.4.4 for ); Tue, 2 Feb 1993 13:10:42 -0500 Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk (4.1/SMI-4.1) id AA23047; Tue, 2 Feb 93 18:10:37 GMT Date: Tue, 2 Feb 93 18:10:37 GMT From: jim@meiko.co.uk (James Cownie) Message-Id: <9302021810.AA23047@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA03318; Tue, 2 Feb 93 18:09:00 GMT To: tony@Aurora.CS.MsState.Edu Cc: mpi-context@cs.utk.edu In-Reply-To: Tony Skjellum's message of Tue, 2 Feb 93 11:14:40 CST <9302021714.AA03830@Aurora.CS.MsState.Edu> Subject: Restricted contexts Content-Length: 4249 > The notion of context implementation for efficiency should not drive > it to be a highly limited field. I'd like the additional cost of contexts to be small. I'd also like it NOT to impact people who don't use contexts. Both of these drive me in the direction of the sort of implementation I was proposing. This is easy provided there are relatively few contexts, hard if they're as anarchic as tags. > It is true that if there are only a > few contexts, then they could be moved to hardware support. Yes, but not the reason for my proposal. I have no desire (or need) to do this. > I think that > large software will have many hundreds of contexts, and that this resource > should be less limited. I can't imagine why you need another 10 bits of context when you already have 32 of tag. What are you going to use the context for ? > I dislike the notion that hardware-specific > details creep into the standard. For instance, CM-5 could/does have 8 > hardware contexts of messages, at a low level, but these are not really > published to the user at all. I agree entirely. My proposal is not based on any specific hardware implementation. (My hardware has a small processor in it which can execute C code and run comms processor threads in a remote user space without requiring any main processor intervention, but I'm not asking for that in the standard !) > The issue of whether one or many queues are supported is completely > separate, and can be addressed separately. Separate queues weaken > the partial ordering guaranteee of a message passing system; ie, that messages > are received in pairwise-preserved order. Hence, they have been avoided > thus far in the work I have done. True, I didn't see this as a problem, since I thought that messages in different contexts could reasonably be unordered with respect to each other. (This was based on my view of what contexts are for, as explained in the intro to my proposal, maybe you have a different use for them in mind ?) > However, there is nothing in principle > wrong with letting an implementation disperse messages as they come in > based on context. The best partial screening for messages is highly > application dependent. Perhaps some type of adaptive hashing could be > used internal to strong implementations, but it should not be required. > For instance, independent of context support totally, adaptive hashing > on type/sender could be incorporated to existing systems. Of course all of these things are possible, and all add to the baseline latency. I was hoping to reduce this, not increase it. > I do not think it too inefficient to test 64 bits instead of 32 bits for > typing. In practice, there are much more serious overheads in a system. > The notion that we have full push-down message stacks, is an example of > this. I haven't seen any proposal in the MPI context which doesn't take this approach, and since I'm not trying to rewrite the whole thing... > Registry is very important, because it guarantees that code (be it user > or other library code) will cooperate reasonably well, given the message > resource. This type of registry is accepted for file systems, for instance, > where we accept that FORTRAN unit number is a bad way to program. Unix > file descriptors provide insulation between different parts of a program. > Same idea for contexts. Exactly. That's why my context proposal is based on the file descriptor model. > Is a context associated with a group? Well, I hope so, but enforcing this > is less important. Groups are very important in and of themselves, and to > have guarantee that a context is available in a group is very useful. It > also makes sense to me that a loosely synchronous registry by a group of > processes to get a context is a good idea. In my model a group can request a context. It does not have one a priori. (Maybe it doesn't need one since it can use one which the relevant processes already have). -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From owner-mpi-context@CS.UTK.EDU Tue Feb 2 13:45:12 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA25590; Tue, 2 Feb 93 13:45:12 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01587; Tue, 2 Feb 93 13:44:48 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 13:44:47 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01579; Tue, 2 Feb 93 13:44:45 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA03874; Tue, 2 Feb 93 12:44:09 CST Date: Tue, 2 Feb 93 12:44:09 CST From: Tony Skjellum Message-Id: <9302021844.AA03874@Aurora.CS.MsState.Edu> To: mpi-context@cs.utk.edu, jim@meiko.co.uk Subject: Re: Restricted contexts Addendum to my previous comments. I do not think it is a bad idea for vendors to provide limited, extremely fast registry mechanisms, like the CM-5's 8 hardware contexts, or whatever Meiko might have in mind along the same lines. These should be viewed as low-level services that can be incorporated into standard interfaces, increasing their performance, when they can be used. Active messages, for instance, while they are lower-level than the MPI ideas, should not be discarded by vendors. They may be a very good way for strong, MPI-upward-compatible, message systems to do a good job with hardware. We must provide for a way for vendors to extract performance from their hardware, within the context of MPI, or else they will continue to gain commercial advantage from ignoring MPI, rather than supporting it fully. - Tony From owner-mpi-context@CS.UTK.EDU Tue Feb 2 13:52:39 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA25863; Tue, 2 Feb 93 13:52:39 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA02049; Tue, 2 Feb 93 13:52:10 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 2 Feb 1993 13:52:09 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA02040; Tue, 2 Feb 93 13:52:08 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA03880; Tue, 2 Feb 93 12:51:25 CST Date: Tue, 2 Feb 93 12:51:25 CST From: Tony Skjellum Message-Id: <9302021851.AA03880@Aurora.CS.MsState.Edu> To: jim@meiko.co.uk, mpi-context@CS.UTK.EDU Subject: Re: Restricted contexts Jim, I do not think it is better to keep it a 8 or 10 bits, rather than 32, for the following reasons 1) alignment 2) comparison cost (8 v. 32) on modern architectures Yes, we are going to use more than 256. Libraries that use processes in multiple configurations, and with multiple sub-groupings generate a number of contexts. I will send you the Zipcode 1.0 tech. doc. later (when finished) and you can see for yourself that many contexts can reasonably be used. For each different library in a system, one could imagine using about twenty of these message contexts. It could be up to the implementor to use more/less, depending on how services are being provided, and how service priorities are set. Tags are an unstructured field. 32 bits for the tag may be too much, but when it is all the programmer has to control selectivity, 32 is a good quantity to choose. Context suggests structuring part of the selectivity. In this case, 32 bits may be more than enough. Real software will use contexts. People who don't use them are the people who will be writing their own codes, using no one else's libraries or codes, and basically not doing the same type of top-down design we expect from good software development. I would argue that people who want to save these incremental test costs will also be unwilling to do anything but drive the hardware from the most primitive system calls. - Tony From owner-mpi-context@CS.UTK.EDU Wed Feb 3 05:35:52 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA18460; Wed, 3 Feb 93 05:35:52 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21954; Wed, 3 Feb 93 05:34:51 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 3 Feb 1993 05:34:50 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from marge.meiko.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21946; Wed, 3 Feb 93 05:34:47 -0500 Received: from hub.meiko.co.uk by marge.meiko.com with SMTP id AA13139 (5.65c/IDA-1.4.4 for ); Wed, 3 Feb 1993 05:34:43 -0500 Received: from float.co.uk (float.meiko.co.uk) by hub.meiko.co.uk (4.1/SMI-4.1) id AA26644; Wed, 3 Feb 93 10:34:39 GMT Date: Wed, 3 Feb 93 10:34:38 GMT From: jim@meiko.co.uk (James Cownie) Message-Id: <9302031034.AA26644@hub.meiko.co.uk> Received: by float.co.uk (5.0/SMI-SVR4) id AA03416; Wed, 3 Feb 93 10:32:56 GMT To: tony@Aurora.CS.MsState.Edu Cc: mpi-context@CS.UTK.EDU In-Reply-To: Tony Skjellum's message of Tue, 2 Feb 93 12:51:25 CST <9302021851.AA03880@Aurora.CS.MsState.Edu> Subject: Restricted contexts Content-Length: 1848 Tony, > I do not think it is better to keep it a 8 or 10 bits, rather than 32, > for the following reasons > > 1) alignment > 2) comparison cost (8 v. 32) on modern architectures Alignment may or may not be an issue. I have no objection to you sending the context as an aligned quadword in the message header if that is faster on your hardware. I'm only interested in the restricting range of valid values. My point is that if I have only a few (8 or 10 bits) then I can use a qualitatively different implementation [an array] than if I have to deal with random 32 bit values. Of course the cost of comparison is the same, but if I only have a few contexts I can remove the comparisons from the loop entirely. > Yes, we are going to use more than 256. Libraries that use processes > in multiple configurations, and with multiple sub-groupings generate a > number of contexts. I will send you the Zipcode 1.0 tech. doc. later > (when finished) and you can see for yourself that many contexts can > reasonably be used. > For each different library in a system, one could imagine using about > twenty of these message contexts. It could be up to the implementor to > use more/less, depending on how services are being provided, and how > service priorities are set. I agree with this, BUT this doesn't mean you need that many contexts all at once. The analogy with unix file descriptors is very close. Each library might use 20 open files, but you can still get by with a limit of 64 or 128 on the number of files open at one time. Similarly with contexts. -- Jim James Cownie Meiko Limited Meiko Inc. 650 Aztec West Reservoir Place Bristol BS12 4SD 1601 Trapelo Road England Waltham MA 02154 Phone : +44 454 616171 +1 617 890 7676 FAX : +44 454 618188 +1 617 890 5042 E-Mail: jim@meiko.co.uk or jim@meiko.com From owner-mpi-context@CS.UTK.EDU Wed Mar 3 16:57:19 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA12038; Wed, 3 Mar 93 16:57:19 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08269; Wed, 3 Mar 93 16:56:38 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 3 Mar 1993 16:56:37 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08261; Wed, 3 Mar 93 16:56:36 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA05229; Wed, 3 Mar 93 15:53:56 CST Date: Wed, 3 Mar 93 15:53:56 CST From: Tony Skjellum Message-Id: <9303032153.AA05229@Aurora.CS.MsState.Edu> To: mpi-context@cs.utk.edu Subject: Status Dear MPI contexts people, Per our agreement at the last MPI meeting, a sub-sub-committee consisting of Cownie, Clarke, and Skjellum are developing a multi- alternative "closure" proposal for MPI. This will be presented to the entire contexts sub-committee within two weeks. After further discussion, at least two viable scenarios, required to resolve group, context, tag, group ID conflicts/overlaps, will be presented at next MPI meeting. You will receive our proposal for review as soon as possible. - Tony From owner-mpi-context@CS.UTK.EDU Mon Mar 8 17:14:45 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA21363; Mon, 8 Mar 93 17:14:45 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA23364; Mon, 8 Mar 93 17:14:16 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Mon, 8 Mar 1993 17:14:15 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA23356; Mon, 8 Mar 93 17:14:14 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA08120; Mon, 8 Mar 93 16:10:45 CST Date: Mon, 8 Mar 93 16:10:45 CST From: Tony Skjellum Message-Id: <9303082210.AA08120@Aurora.CS.MsState.Edu> To: mpi-context@cs.utk.edu Subject: PRECIS for closure proposal Please comment. - Tony Skjellum ---------------------------------------------------------------------------- Here is the precis of the post-MPI meeting... Input was from Skjellum, Littlefield, Pierce, Ranka [and others I don't recall specifically]. There shall be three self-consistent "closures" for MPI, that completely remove inconsistency between the usage of the following concepts (while fully defining the following concepts): 1) tag 2) context 3) group 4) process ID It is our task to assemble such proposals and to place them before the context sub-committee prior to the next meeting, and provide a refined set of proposals (with recommendations) before the full committee at the next MPI meeting. The first reading of this section of the standard is needed to make the rest of the standard go forward. --------------------------------------------------------------------- Proposal I. GROUP ID = CONTEXT = OBJECT, aka "Snir" model groups, contexts, objects are local and opaque. naming of processes is group-relative. this option was discussed, in most part, by Snir at meeting. Proposal II. GROUP ID != CONTEXT, aka "Littlefield" model GROUP corresponds to "data/instance" in this model CONTEXT is statically defined at link time, corresponding to code or class In this model, group ID's appear explicitly, and separately from CONTEXTS in global operations. It was noted by Littlefield that he would write global operations, and product bits of the GROUP ID and static CONTEXT to guarantee that his code produced unique, deterministic, non-interfering results. Proposal III. GROUP ID null, GROUP scope == CONTEXT scope, aka Zipcode model CONTEXT is a dynamic concept, and global (or as global as necessary) Whenever a group is created, a context is assigned to it. CONTEXTS are used to disambiguate global operations. GROUP ID is the CONTEXT for the group. GROUP is an enumeration of PROCESS ID's OR ONE OF SEVERAL possible hashing formulas, with exceptions (more scalable) Proposal IV. GROUP ID != CONTEXT, aka fully "object-oriented" model CONTEXT is a dynamic concept, and global (or as global as necessary) GROUP ID is emasculated, in the sense that there are process groups, but CONTEXT is still needed in global operations The general case of "code U data" (the object-oriented model) is taken, with context+group forming a scope in the system. The "Server model," where CONTEXTS that have no group association made to them, is to be supported. GROUP is an enumeration of PROCESS ID's OR ONE OF SEVERAL possible hashing formulas, with exceptions (more scalable) ---------------------------------------------------------------------- Requirements for all proposals to meet closure 1) All global operations must be describable in terms of point-to-point operations without loss of generality 2) Global operations, including non-blocking barriers, and so on, must work correctly with overlapping process groups 3) There must be reasonable/scalable mechanism for assigning contexts 4) Tag usage seems to be non-controversial according to above discussion, but we need to watch out for the following. 1) desire to use part of tag for context, group ID or other field, and make that part of the standard 5) Provision of enough contexts to support all describable or reasonable scenarios that we can justify, but not more than are foreseeable, because there could be a performance penalty by requiring the number of contexts to be too great. 6) Justification is perceived to be required for dynamic contexts (why?) 7) A fully consistent definition for how process IDs are to work. 8) An explanation of how to extend to dynamic groups later, if possible. From owner-mpi-context@CS.UTK.EDU Tue Mar 9 18:14:44 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA16448; Tue, 9 Mar 93 18:14:44 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03977; Tue, 9 Mar 93 18:13:41 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 9 Mar 1993 18:13:39 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from antares.mcs.anl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03969; Tue, 9 Mar 93 18:13:37 -0500 Received: from godzilla.mcs.anl.gov by antares.mcs.anl.gov with SMTP id AA15144 (5.65c/IDA-1.4.4 for ); Tue, 9 Mar 1993 17:13:34 -0600 From: William Gropp Received: by godzilla.mcs.anl.gov (4.1/GeneV4) id AA12285; Tue, 9 Mar 93 17:13:30 CST Date: Tue, 9 Mar 93 17:13:30 CST Message-Id: <9303092313.AA12285@godzilla.mcs.anl.gov> To: tony@aurora.cs.msstate.edu Cc: mpi-context@cs.utk.edu In-Reply-To: Tony Skjellum's message of Mon, 8 Mar 93 16:10:45 CST <9303082210.AA08120@Aurora.CS.MsState.Edu> Subject: PRECIS for closure proposal The one point in Tony's excellent summary that needs more elaboration is needed on whether process id's, when being used in point-to-point operations, are group-relative (ranks) or absolute (and possibly opaque). Only Proposal I specifies this (ids = ranks); the others leave this unspecified. In the interests of keeping the latency down, I'd like them to be absolute, at least at the lower levels. In any event, this choice is a critical one but one that is mostly orthogonal to the other issues. In fact, I'd have chosen absolute process id's as the "Snir" model. Bill From owner-mpi-context@CS.UTK.EDU Tue Mar 9 18:40:34 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA16750; Tue, 9 Mar 93 18:40:34 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05349; Tue, 9 Mar 93 18:40:04 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 9 Mar 1993 18:40:01 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from [129.215.56.21] by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05321; Tue, 9 Mar 93 18:39:58 -0500 Date: Tue, 9 Mar 93 23:39:42 GMT Message-Id: <2472.9303092339@subnode.epcc.ed.ac.uk> From: L J Clarke Subject: Re: PRECIS for closure proposal To: William Gropp In-Reply-To: William Gropp's message of Tue, 9 Mar 93 17:13:30 CST Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu Bill writes: > In the > interests of keeping the latency down, I'd like them to be absolute, at least > at the lower levels. In any event, this choice is a critical one but one > that is mostly orthogonal to the other issues. In fact, I'd have chosen > absolute process id's as the "Snir" model. I think we all realise what your choice would be Bill :-) There are arguments both ways, perhaps we should have both. On the other hand, the speed demons probably should be advised to use the communication handle layer at which any overhead of mapping (group,rank) to absolute-implementation-specific-best-you-can-get, and other per initialisation overheads, should be paid exactly once in the handle initialisation. Isn't that exactly why we have this layer? Best Wishes Lyndon /--------------------------------------------------------\ e||) | Lyndon J Clarke Edinburgh Parallel Computing Centre | e||) c||c | Tel: 031 650 5021 Email: lyndon@epcc.edinburgh.ac.uk | c||c \--------------------------------------------------------/ From owner-mpi-context@CS.UTK.EDU Tue Mar 9 18:42:28 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA16757; Tue, 9 Mar 93 18:42:28 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05578; Tue, 9 Mar 93 18:42:14 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Tue, 9 Mar 1993 18:42:13 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from daedalus.epcc.ed.ac.uk by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA05570; Tue, 9 Mar 93 18:42:10 -0500 Date: Tue, 9 Mar 93 23:42:06 GMT Message-Id: <2480.9303092342@subnode.epcc.ed.ac.uk> From: L J Clarke Subject: Re: [d39135@sodium.pnl.gov: Re: group descriptors] To: Tony Skjellum , Jim Cownie , Rik Littlefield , Sanjay Ranka Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu Rik writes: > > PS. Tony, I'm a little surprised that your reply to me was not > broadcast, especially considering your reaction to being left > out of a loop earlier. > > I am also concerned that this group is not leaving a publicly > accessible trail. These discussions have a lot of content > that should be available to others even if it does not appear > in the final proposal. > > Should we not be using an mpi-contexts reflector and archiver at > Oak Ridge? > I'm beginning to think this is correct. We seem to be talking things which seem to go beyond the "Four Proposals" agreement. Best Wishes Lyndon /--------------------------------------------------------\ e||) | Lyndon J Clarke Edinburgh Parallel Computing Centre | e||) c||c | Tel: 031 650 5021 Email: lyndon@epcc.edinburgh.ac.uk | c||c \--------------------------------------------------------/ From owner-mpi-context@CS.UTK.EDU Wed Mar 10 00:36:37 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA21055; Wed, 10 Mar 93 00:36:37 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18558; Wed, 10 Mar 93 00:36:04 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 00:36:03 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18550; Wed, 10 Mar 93 00:36:02 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA09605; Tue, 9 Mar 93 23:30:48 CST Date: Tue, 9 Mar 93 23:30:48 CST From: Tony Skjellum Message-Id: <9303100530.AA09605@Aurora.CS.MsState.Edu> To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, ranka@top.cis.syr.edu Subject: Re: [d39135@sodium.pnl.gov: Re: group descriptors] Cc: mpi-context@cs.utk.edu I am not sure to which comment I incorrectly misresponded. Rik, please remind me... I think there are a total of two letters which are improperly sent only to you, and I do want them shared with everyone. I was quite rushed today, and hit the wrong R key, no doubt. To my recollection, both deal with Methods within group/contexts. If you want to elaborate mailing to entire mpi-contexts subcommittee, I concur. Let's make sure all of you are on that list, so we don't lose track of the main discussion people, however. So, my basic request to Rik is that he echo the two letters sent to him alone, which was my error. Mea culpa. :-) Tony From owner-mpi-context@CS.UTK.EDU Wed Mar 10 01:10:06 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA21883; Wed, 10 Mar 93 01:10:06 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA19605; Wed, 10 Mar 93 01:09:48 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 01:09:47 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA19597; Wed, 10 Mar 93 01:09:46 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA09722; Wed, 10 Mar 93 00:05:40 CST Date: Wed, 10 Mar 93 00:05:40 CST From: Tony Skjellum Message-Id: <9303100605.AA09722@Aurora.CS.MsState.Edu> To: d39135@sodium.pnl.gov Subject: Re: group descriptors Cc: jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu This corrects the second message, accidently sent only to Rik. - Tony From tony Tue Mar 9 23:23:17 1993 To: d39135@sodium.pnl.gov Subject: Re: group descriptors Content-Length: 897 Rik, I was foolish not to mention that we have implemented a registration mechanism with trees, in Zipcode 1.0. The user can add available methods for combine, and then,when a mailer is created, specific choices can be taken from the list. Currently, we implement with numbers, but this could be done with names, to allow better sharing. I will check on choices we made. It has been some time since I worked on that internal code. Anyway, I concur on the need to have registerable choices, that allow sharing, per your letter. As regards new functionality, they could go in the tree too, but there is no structural mechanism in Zipcode, other than defining a class' method list, for adding new instantiations to a mailer at creation. All of this was very elaborate coding, which I will elucidate in my article for Rolf. I am happy to share details with you as well, beforehand. - Tony From owner-mpi-context@CS.UTK.EDU Wed Mar 10 06:16:34 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA13775; Wed, 10 Mar 93 06:16:34 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA06917; Wed, 10 Mar 93 06:15:36 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 06:15:33 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA06900; Wed, 10 Mar 93 06:15:29 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA09848; Wed, 10 Mar 93 05:10:50 CST Date: Wed, 10 Mar 93 05:10:50 CST From: Tony Skjellum Message-Id: <9303101110.AA09848@Aurora.CS.MsState.Edu> To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@aurora.cs.msstate.edu Subject: re: static contexts writeup [My comments prepended with **** - Tony] **** In mail immemorial, Rik agreed to merge his (enclosed) write-up with **** the first-generation PRECIS, to generate a more useful one, **** Please correct me if I am wrong, but I cannot find this! **** (Again, I apologize for calling this a PRECIS, not a SKETCH.) **** I want to generate the next version of this SKETCH/PRECIS, **** with specifics garnered from our lengthy bantering and **** discussions. Particularly, I will discuss the sparse matrix **** of proposals X closure options. Lyndon, you indicated that **** one of my comments challenged you to make a new added entry **** to one of the proposal categories. May I have that now/soon? **** **** In interest of refocusing discussion, I will work on such a **** new PRECIS/SKETCH, reviewing all the mail flurry from last days, **** and then suggest writing assignments. Lyndon will be off-line, but **** Lyndon will still get some brain work to do off-line. :-) Lyndon **** will you phone me periodically, to stay abreast of things? **** Perhaps we will need the manpower of Rusty/Bill to help us, given **** the amount of work on filling the sparse matrix of issues. Willing? **** **** Our PRECIS/SKETCH and work from it will not address the following things **** (related to discussion in our group, but not central to it): **** - the fully portable MPI program **** - I/O **** - the semantics and syntax of process management **** - the time-table for MPI-1,MPI-2,MPI-3,... **** In a truly global sense, these could be construed to be closure as **** well, but I want to exclude them for sanity reasons. I do believe **** that parts of these issues could be addressed within MPI-1, but **** it is not now this subcommittee's role to do that for MPI at-large. **** Strong objections? If so, we are in deep trouble:-) **** **** We will assume that discussion in this 4-proposal X closure effort is **** all essential to MPI-1. Anything you really don't think is essential **** for MPI-1... once we agree to same .... should probably get deferred. **** Is that controversial? **** **** I thank everyone for their sincere efforts. **** - Tony **** **** PS Per constructive advice from Rik, all of my mail is getting copied to **** mpi-context now. All should do so. I did not hear any dissent **** about this suggestion, and it adds potential help to **** discussion. As we need the help, and few people are writing **** anyway, this will not likely cause problems. **** Continue to include the five names jim, lyndon, tony, sanjay & **** Rik, incase any of us are not on the mpi-context mailing list!!! **** **** PPS Lyndon, where are you. I got up at 4am to read the next round **** of mail from you, but none to be found :-) **** **** Rik writes... >Before it gets TOO stale, here's a copy of my writeup on static >contexts et.al. as it last went to Lyndon and Tony. (You two can >stop reading at the line of dashes.) > >I have opted not to hack on static contexts any more because I >would rather kill them. **** Is this a proposal to include static contexts as in within **** the 4-proposal model, and that we stop working on same? **** If so, I can make it so... >I now suspect that I would trade static contexts for something >like the MPI_set_group_attribute cacheing facility that I have >outlined in recent email. I will think more about this and get >back to you. > >In the meantime, I would very much like more feedback on the >cacheing facility, especially how it breaks. > >Thanks, >--Rik > >---------------------------------------------------------------------- > >This note discusses message context ID's -- what they're good for, >how to generate them, how to use them. > >Credits.. At the last Dallas meeting, Mark Snir asked me to write >up some thoughts on this topic and to send them around to the >whole committee. Paul Pierce, Tony Skjellum, several other >people (whose names I can't remember) and I discussed some of the >ideas over lunch on the last day. Then Lyndon Clarke of the >contexts subcommittee emailed me asking for some clarification of >static context generation, which I guess I'm the main proponent >of. He reviewed an earlier (and even longer) draft of this note, >and it is now much improved. (Thanks, Lyndon!) However, I have >substantially rewritten it since talking with any of those folks, >so I have to take full blame for the fallacies of this version. > >1. Notation and assumptions > > In this note, I assume that > > . "context ID" means a message selection field > that cannot be wildcarded, > > . "tag" means a message selection field > that *can* be wildcarded, and > > . context ID, tag, and process ID are the *only* fields > that can be used for pt-pt message selection. > > In particular, I assume that "group ID" cannot be used for > selection unless it is somehow propagated into the tag or > context ID fields. > > I will speak of "modules" that operate within "groups". By > "module", I mean a procedure (subroutine) or collection of > procedures that can exploit knowledge of each other's internal > workings in order to coordinate their message passing. By > "group", I mean a collection of processors identified by a > globally unique "group ID". By "operating within a group", I > mean that the module is called simultaneously by all processes > belonging to the group and exchanges messages primarily with > those copies of itself. (I assume that arbitrary communication > is always possible. The focus of this discussion is how to > make restricted communication easy.) I assume that the group > ID is passed into the module. > > I will also speak of an "instance of a module". By this, I > mean a module, plus the group that it is operating in, plus the > data it is working on. (The latter becomes important if the > module supports nonblocking operation. In that case, I assume > that some data ID is passed into the module. An example is the > 'tag' argument of the nonblocking collective routines.) > > My notation requires that independently written modules can be > called sequentially within the same group. Specifically, if a > a group must be "duplicated" in order to guarantee that two > modules do not conflict, then I will say that those modules are > operating in different groups. > > By definition, independent modules do not coordinate their use > of tags. (A module can of course coordinate with itself. > That's what tags are for.) > >2. Why do we want context ID's? > > The most important purpose of context ID's is to avoid message > collisions between independent modules. (This is the only way > to avoid such collisions, since coordination of tag values is > excluded by definition.) > > Context ID's are sometimes also be the best way to avoid > collisions between instances of the same module. (This depends > on the definition of "best", as discussed below.) The tag > field can also be used for such avoidance, since the module has > full control over how the tags are used. > >3. Desirable features of contexts and groups: > > I think there will be little debate about these: > > A. It should easy to write modules that don't conflict with the > same or other modules, even when the modules are called > within overlapping groups. (Or, save us all, with multiple > outstanding non-blocking operations.) > > B. It should be easy to call these modules. > > There may be more debate about these, but I like them as sanity > checks: > > C. The MPI routines that manage groups and contexts should > be definable in terms of MPI point-to-point communication > and process-local operations. > > (For example, I get nervous about group and context > management semantics that require asynchronous servers or > their equivalent, like an asynchronous atomic > fetch-and-increment. We already decided to eliminate > interrupt receive at the user level, on the argument that > it was too hard to implement correctly. Asynchronous > servers are a bit easier, since they can run on > resources other than the processes calling MPI, but > personally I would rather avoid servers if possible.) > > D. The "closed-system constraint": standard global operations > (e.g., broadcasting within a group) should be definable in > terms of MPI point-to-point and group/context operations. > > (For example, we must be careful to avoid bootstrap > problems like needing a context specific to a group, in > order to create the group.) > >3. How do modules get and use context ID's ? > > Assume that we have already created a group and distributed its > group ID, and that we have a mechanism for broadcasting within > the group. (More on this later.) > > Then we have at least the following options for managing > context ID's: > > Option 1. "Context ID = group ID" (and no group-dup'ing). > > By my definition of "same group", i.e. dup'ing gets you > a different group, this option means that two modules can > get called back-to-back with the same context. > > I think this is OK, courtesy sequencing constraints, if and > only if both modules use exact match on tag and source. > Since the group ID is already available (passed in), this > provides a simple and efficient mechanism for many useful > algorithms, such as blocking global ops. > > This option fails, however, with modules that use wildcard > tag or source. (I won't bother to provide an example -- > having the same context is the same as having no context, > and we know what havoc that creates.) > > Option 2. One process obtains from MPI a unique context ID > for each instance of a module, and distributes it > for that instance's use. > > I believe that this is the strategy proposed by Tony Skjellum > in his 3-page handout at Dallas. The distribution might be > done either within a module or by its caller. Presumably > there are more callers than modules, so doing it within the > module is preferred. As noted above, distribution of the new > context can be done with a broadcast using exact match on > tag and source, with context=group, presuming of course that > the module follows the rule of doing wildcard matches only > in a different context. > > In the Dallas discussions, it seemed to be assumed that this > option requires an asynchronous server, since the context > generation calls have to be coordinated to ensure uniqueness > but can occur at any time. This bothered me. > > However, I realized while writing this note that this option > can also be done without a server by having a process-local > pool of preassigned context ID's. For example, let the > bottom bits of a context ID be the ordinal (in some global > numbering scheme) of the process that assigned it, and manage > the upper bits however you would in a server. For P > processes, this would require at most log(P) extra bits in > the context field, compared to having a server. > > So now my main concerns about this approach are the extra > communication to distribute the context ID's, plus a nagging > feeling that there's still a bootstrap problem if this is > the only option. > > Option 3. "Static context ID's" > > This is the option that I pushed at the Dallas meeting. > > The idea is that each module gets a context ID that is based > solely on a source code key, then manages its tag values to > keep the groups and instances separate. > > To be definite, assume that a module can obtain a context ID > via a call like > > error = MPI_get_context_for_name (name, &contextID) > > where is the character string unique to the module, and > the generated context ID depends only on the supplied name. > This call is made independently on all processes wishing to > share the context. > > The simplest convention would be to require that be > the name of a procedure within the module. That way the > linker guarantees uniqueness. There are other ways to get > unique strings, such as the "dollar bill algorithm" and > whatever strategies people use to reserve names for expansion > of libraries, but these do not affect the basic idea. > However, you cannot use the address of a routine in place of > its name, since this would not work in heterogeneous systems. > > The most efficient strategy is to require that all names be > "registered offline". By this, I mean that MPI be given a > list, prior to execution, of all the names that might be > passed to MPI_get_context_for_name by this particular > program. There are several ways that this could be > accomplished. For example, if we require that the names > always be those of modules, then a (conservative) list can be > generated at link time using Unix 'nm' or equivalent. > > With offline registration, MPI_get_context_for_name can > be implemented so as to require no communication at all. > > We can go farther and require that be a constant > string, in which case the call to MPI_get_context_for_name > could be implemented as a compile-time macro substitution. > (I hate citing it, but as precedent I note that this strategy > is used by the optimizer for some versions of 'Linda'.) > > Without offline registration, it seems that MPI_get_context_for_name > would require an asynchronous server. I will not discuss this > further because in my view static contexts are intended to > make for simple implementations and fast execution. > > OK, now we can quickly and efficiently (zero execution > cost) get a context ID that is unique to the module, but all > instances of that module have to share the context. (Please, > no kneejerk reactions -- hear me out before labeling this as > a stupid idea in complete violation of the spirit of contexts.) > > How does the module keep multiple instances straight? > It uses the message tag field. > > The idea is to generate an MPI tag value by smushing together > the group ID, data ID (if needed), and the nominal tag value > that the module would have used if it didn't have to worry > about multiple instances. No other module cares how the > smushing is done -- the context is unique and we have agreed > that modules can use the tag bits however they want. This is > just an example of a module coordinating with itself > regarding how to handle the tag bits. > > Yes, this scheme does seem like jumping through a hoop, but > it does have some advantages. If the group and data ID's are > short enough to be smushed into a message tag without losing > any bits, then the MPI tag can be generated with absolutely > no communication. This means that: > > 1. It provides a method to implement other group > and context management functions that is bulletproof > and free of bootstrap problems. > > 2. It executes fast. > > To understand the first advantage, consider the problem of > how to implement MPI_close_group(gid) using only MPI pt-pt > operations. Remember that the module executing within that > group on other nodes can legitimately still have a wildcard > receive posted. If MPI_close_group tries to use the group > context, its messages can get eaten. Sync the group first? > That just means you have the same problem implementing sync. > Having static contexts for MPI_close_group and/or sync solves > this problem. Are there other solutions for which MPI pt-pt > operations would be sufficient? > > The second advantage is perhaps weaker, but I for one keep > finding myself writing modules that are sensitive to > communication performance, particularly latency. In many > cases, I would prefer to write a few extra lines of code than > to use functionality that would cost extra messages. I > have lots of experience with tag-smushing due to working > with low-functionality communication systems (like select > on message tag only, and no useful wildcarding). I find > that extra coding effort is very small. Typically it's > embedded in a macro call or cover routine, so that I still > have to write only one line of code to handle a message. > > Note that I do NOT propose static contexts as a solution for > everyone. However, they are useful for speed, and may be > required under the closed-system constraint. > >4. Summary > > It looks to me like all three options presented here are > complementary. They might all might be provided, in the > expectation that they will be used by different audiences. > >Questions, comments? > >--Rik Littlefield > > From owner-mpi-context@CS.UTK.EDU Wed Mar 10 06:34:10 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA17635; Wed, 10 Mar 93 06:34:10 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA07441; Wed, 10 Mar 93 06:33:22 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 06:33:21 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA07433; Wed, 10 Mar 93 06:33:19 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA09870; Wed, 10 Mar 93 05:28:59 CST Date: Wed, 10 Mar 93 05:28:59 CST From: Tony Skjellum Message-Id: <9303101128.AA09870@Aurora.CS.MsState.Edu> To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@CS.UTK.EDU Subject: latest lyndon-mail **** My latest comments start lines with ****. **** - Tony >From lyndon@epcc.ed.ac.uk Wed Mar 10 05:12:18 1993 >Received: from epcc.ed.ac.uk (daedalus.epcc.ed.ac.uk) by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); > id AA09849; Wed, 10 Mar 93 05:11:49 CST >Date: Wed, 10 Mar 93 11:14:44 GMT >Message-Id: <2772.9303101114@subnode.epcc.ed.ac.uk> >From: L J Clarke >Subject: [Tony Skjellum: Re: [Tony Skjellum: Re: Intra/inter group communications, UBONBOUND, PIDs]To: Tony Skjellum , Jim Cownie , > Rik Littlefield , > Sanjay Ranka >Reply-To: lyndon@epcc.ed.ac.uk >Apparently-To: ranka@top.cis.syr.edu >Apparently-To: d39135@sodium.pnl.gov >Apparently-To: jim@meiko.co.uk >Apparently-To: tony@aurora.cs.msstate.edu >Status: R > >Good morning > >Lyndon replying to Tony replying to Lyndon replying to Tony replying to ... > > >> >(again). Please help. >> > >> >First way, "context" is being used to indicate is a binding of group >> >plus more, and therefore I understand it easily. >> > >> >Second way, "context" is being used in a way which I understand. >> > >> ***** I think my comment made more sense to me when I wrote it before. >> ***** I withdraw it. > >Arrrghhhh! I realise that I have badly typed the "Second way", which >should say that "context" is being used in a whay which I do not >understand. This is very badly typed indeed, apologies. > >I think this was a request for information/sharing of understanding, >which I expect I still need. **** I was viewing the whole context-thing as a "port" specification. **** How about a domain-wide name for a piece of mail to be delivered? **** Such as mail from UK to US? **** I am still not sure this was cogent... **** >> >The point is that you do not actually want to produce a new group. You >> >want to keep thinking of the two groups as seperate entities, each >> >acting individually in a coherent fashion, and communicating with one >> >another perhaps according to some rules based on ranks in each >> >indicidual group. >> ***** I understand that, but why do you want to keep thinking of it that way, >> ***** except for some possible performance benefit? >> **** > >I tell you why, it's because we find it easy to think of it and discuss >it in that way. This really is the whole point, expressive power. **** **** I believe in the expressive-power argument, no problem. I am **** also willing to believe that we should keep the minimum cost of **** inter-group down to the point where it remains useful. It is **** dynamicism of groups that motivates inter-group communication. **** Else, the one-shot cost of merging groups, and staying intra-group **** would not be unacceptable. There must be some ineffable quality **** of groups (dynamic need to change, for instance) that you hope for! **** I agree with this abstractly, but please help me more... **** >> > >> >Same "I can read this two ways" as above. >> ***** OK, I withdraw this remark too. > >Look, I found it vague. I'd rather you helped me to understand, please. > **** Related thoughts... **** I am trying to understand my original comment, myself. I think **** of context/group/rank_id as a MPI_TID, if you wish. It all made more **** sense to me structured that way, rather than having a pair of **** contexts as a mechanism for inter-group. In short, I felt we were **** inventing our own TID called context/group/rank_id, and that this **** was a nice structure, and superceded the PVM notion of a TID. **** If I am foggy, sorry, but if we worked in those terms, with accessors **** on such a TID, we would know how to handle some of the problems **** described elsewhere. For instance, we could have the meaning of **** rank_id be group-scope/dependent. Rank would be a nice, fast hash on **** static groups, and a slower, more complex thing to map for **** intergroup [are people still liking NUL/UNBOUND???]. **** >> > >> >If this is an invitation to add a further proposal to the set we are >> >doing, then I accept such invitation. In fact, I can frame it as an >> >extension of proposal I. >> ***** YES. > >Will do. > >> > >> >> Of course, point-to-point could provide another set of procedures which >> >> handle inter-group communication cleanly. This is my preferred >> >> approach, but again I don't suppose that this will be acceptable, >> >> because so may people are already so concerned about the number of >> >> procedures in the point-to-point section. >> >> **** >> >> **** Again, why not try. We need to fill in our matrix of proposals X >> >> **** closures :-) >> >> **** >> > >> >Because I perceive that it would be like trying to drag a dead whale >> >along a beach :-) (You never tried that? I can tell you, its hard work >> >and slow going!) >> ***** Acknowledged. > >Ah, so you tried pulling a dead whale as well. Funny old world :-) > >> ***** I think I was interested in implementation with p2p, because >> ***** of the degrees of freedom inside an MPI envelope dictated by >> ***** some kinds of transcations. These transactions might, for >> ***** instance, motivate >> ***** 1) support of more than K contexts (where K is currently like 256) >> ***** 2) require dynamic contexts which are separate from group ID's >> ***** >> ***** Hence, by asking how the functions are to be done, I am asking >> ***** for possible justifications for the more general context model. >> ***** If hidden contexts are needed to do some of these things, >> ***** perhaps they could be justifiably be accomplished with an open >> ***** context mechanism. >> ***** >> ***** That was my motivation. - Tony >> ***** >> > >I'll think about these comments, but I suspect there is a language >barrier in operation here. > >Best Wishes >Lyndon > **** Lyndon, we know that these functions will have to be implemented some how. **** MPI itself might provide such mechanisms as published functionality or **** hidden functionality. If published functionality is denied in the **** standard (eg, general context management) because we cannot justify it **** properly, but must be implemented internally for most/all complying **** versions of MPI, then I think we lose out. My vague way of stating **** the requirement was to reveal the possibility of this, and thereby to **** promote such internal degrees of freedom into the public part of MPI, **** so applications can use them... Does that help???? **** - Tony From owner-mpi-context@CS.UTK.EDU Wed Mar 10 07:01:54 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA23631; Wed, 10 Mar 93 07:01:54 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08660; Wed, 10 Mar 93 07:01:08 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 07:01:07 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from daedalus.epcc.ed.ac.uk by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA08652; Wed, 10 Mar 93 07:00:58 -0500 Date: Wed, 10 Mar 93 12:00:52 GMT Message-Id: <2831.9303101200@subnode.epcc.ed.ac.uk> From: L J Clarke Subject: Re: [Tony Skjellum: re: static contexts writeup] To: Tony Skjellum , Jim Cownie , Rik Littlefield , Sanjay Ranka Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu Tony writes: > **** PPS Lyndon, where are you. I got up at 4am to read the next round > **** of mail from you, but none to be found :-) > **** First off, many thanks to Tony for getting to his terminal at 4am. I really appreciate the effort to be UK compatible. I fell asleep at mine about 2am and then went home unable to stir mental activity. From 9am to 11am I was in meetings. I had a fair bit of mail to read, but more replies to my copious mail of last night yet expected. You should have got two messages beiefly describing some fairly basic inter-group communications kind of things that are important to me. I'll make as much time today as I can, but as I said last night, I have a hell of a lot of other things to get through as well today. I will come in additionally tomorrow morning from 9am to 10:30 am, to catch up on any further discussion developments. Then I really have to get on the train. > **** In mail immemorial, Rik agreed to merge his (enclosed) write-up with Hey, I got about uncountable copies of Rik's note saved away, now another one :-) > **** Lyndon, you indicated that > **** one of my comments challenged you to make a new added entry > **** to one of the proposal categories. May I have that now/soon? challenged?, invited! Soon, Tony, soon. > **** Lyndon will be off-line, but > **** Lyndon will still get some brain work to do off-line. :-) :-) I can write up Proposal I, and Ib (Lyndon extension amendment) while away. > **** Lyndon > **** will you phone me periodically, to stay abreast of things? Okay, but this will be after 8pm my time, as the calls will come out of my pocket and appear on my parents 'phone bill, and its cheaper then, and they'll have to be real short. > **** Our PRECIS/SKETCH and work from it will not address the following things > **** (related to discussion in our group, but not central to it): > **** - the fully portable MPI program I vote we exclude from our discussion. > **** - I/O I vote we exclude from our discussion. > **** - the semantics and syntax of process management Perhaps something of this should be thought about. Quick thoughts/suggestions: * Create new process group (blob of processes :-) * Resize existing process group (shrink/grow blob, synchronously in blob) > **** - the time-table for MPI-1,MPI-2,MPI-3,... I vote we exclude from our discussion. > **** In a truly global sense, these could be construed to be closure as > **** well, but I want to exclude them for sanity reasons. I do believe > **** that parts of these issues could be addressed within MPI-1, but > **** it is not now this subcommittee's role to do that for MPI at-large. > **** Strong objections? If so, we are in deep trouble:-) No objections. > **** > **** We will assume that discussion in this 4-proposal X closure effort is > **** all essential to MPI-1. Anything you really don't think is essential > **** for MPI-1... once we agree to same .... should probably get deferred. > **** Is that controversial? Not controversial. > **** I thank everyone for their sincere efforts. - ditto - > **** PS Per constructive advice from Rik, all of my mail is getting copied to > **** mpi-context now. All should do so. I did not hear any dissent > **** about this suggestion, and it adds potential help to > **** discussion. As we need the help, and few people are writing > **** anyway, this will not likely cause problems. > **** Continue to include the five names jim, lyndon, tony, sanjay & > **** Rik, incase any of us are not on the mpi-context mailing list!!! Concur, being done. > > > **** Rik writes... > > >Before it gets TOO stale, here's a copy of my writeup on static > >contexts et.al. as it last went to Lyndon and Tony. (You two can > >stop reading at the line of dashes.) > > > >I have opted not to hack on static contexts any more because I > >would rather kill them. > **** Is this a proposal to include static contexts as in within > **** the 4-proposal model, and that we stop working on same? > **** If so, I can make it so... I'd like us to now ask Rik to write Proposal II. Best Wishes Lyndon /--------------------------------------------------------\ e||) | Lyndon J Clarke Edinburgh Parallel Computing Centre | e||) c||c | Tel: 031 650 5021 Email: lyndon@epcc.edinburgh.ac.uk | c||c \--------------------------------------------------------/ From owner-mpi-context@CS.UTK.EDU Wed Mar 10 08:37:24 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA28930; Wed, 10 Mar 93 08:37:24 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12056; Wed, 10 Mar 93 08:36:57 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 08:36:56 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from daedalus.epcc.ed.ac.uk by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12047; Wed, 10 Mar 93 08:36:43 -0500 Date: Wed, 10 Mar 93 13:36:37 GMT Message-Id: <2981.9303101336@subnode.epcc.ed.ac.uk> From: L J Clarke Subject: Re: [Tony Skjellum: re: static contexts writeup] To: Tony Skjellum , Jim Cownie , Rik Littlefield , Sanjay Ranka Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu Proposal Ib Proposal Ib extends Proposal I (nee aka "snir" model) to provide group identification and inter-group communication for static (constant membership) groups. Group identification is effected by: facilities to send group in message; group registry service Inter-group communication needs to extend the basic (group,rank) notation. Two suggestions will be offered: procedures to do this; syntactic trickery (see previous emails). Regards Lyndon /--------------------------------------------------------\ e||) | Lyndon J Clarke Edinburgh Parallel Computing Centre | e||) c||c | Tel: 031 650 5021 Email: lyndon@epcc.edinburgh.ac.uk | c||c \--------------------------------------------------------/ From owner-mpi-context@CS.UTK.EDU Wed Mar 10 11:12:48 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA03467; Wed, 10 Mar 93 11:12:48 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA20567; Wed, 10 Mar 93 11:12:19 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 11:12:18 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from daedalus.epcc.ed.ac.uk by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA20557; Wed, 10 Mar 93 11:12:11 -0500 Date: Wed, 10 Mar 93 16:12:01 GMT Message-Id: <3127.9303101612@subnode.epcc.ed.ac.uk> From: L J Clarke Subject: Re: private message To: Tony Skjellum In-Reply-To: Tony Skjellum's message of Wed, 10 Mar 93 10:00:55 CST Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu No problem. This would be just fine. I perfer not to have to administrate it, especially as I will be off-line and therefore unable to service administration requests. Can I suggest that the address be precis@aurora.cs.mssatte.edu :-) /--------------------------------------------------------\ e||) | Lyndon J Clarke Edinburgh Parallel Computing Centre | e||) c||c | Tel: 031 650 5021 Email: lyndon@epcc.edinburgh.ac.uk | c||c \--------------------------------------------------------/ From owner-mpi-context@CS.UTK.EDU Wed Mar 10 11:32:09 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA03864; Wed, 10 Mar 93 11:32:09 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21943; Wed, 10 Mar 93 11:31:32 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 11:31:29 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from Aurora.CS.MsState.Edu by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA21932; Wed, 10 Mar 93 11:31:27 -0500 Received: by Aurora.CS.MsState.Edu (4.1/6.0s-FWP); id AA10032; Wed, 10 Mar 93 10:25:42 CST Date: Wed, 10 Mar 93 10:25:42 CST From: Tony Skjellum Message-Id: <9303101625.AA10032@Aurora.CS.MsState.Edu> To: tony@aurora.cs.msstate.edu, jim@meiko.co.uk, d39135@sodium.pnl.gov, ranka@top.cis.syr.edu, lyndon@epcc.ed.ac.uk Subject: Re: [Tony Skjellum: re: static contexts writeup] Cc: mpi-context@cs.utk.edu **** My latest comments appear prepended with for ****'s. **** -Tony ----- Begin Included Message ----- From owner-mpi-context@CS.UTK.EDU Wed Mar 10 05:58:24 1993 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 07:01:07 EST Date: Wed, 10 Mar 93 12:00:52 GMT From: L J Clarke Subject: Re: [Tony Skjellum: re: static contexts writeup] To: Tony Skjellum , Jim Cownie , Rik Littlefield , Sanjay Ranka Reply-To: lyndon@epcc.ed.ac.uk Cc: mpi-context@cs.utk.edu Content-Length: 4438 Tony writes: > **** PPS Lyndon, where are you. I got up at 4am to read the next round > **** of mail from you, but none to be found :-) > **** [comments on interactions over next day omitted, :-)] **** In mail immemorial, Rik agreed to merge his (enclosed) write-up with Hey, I got about uncountable copies of Rik's note saved away, now another one :-) > **** Lyndon, you indicated that > **** one of my comments challenged you to make a new added entry > **** to one of the proposal categories. May I have that now/soon? challenged?, invited! Soon, Tony, soon. > **** Lyndon will be off-line, but > **** Lyndon will still get some brain work to do off-line. :-) :-) I can write up Proposal I, and Ib (Lyndon extension amendment) while away. > **** Lyndon > **** will you phone me periodically, to stay abreast of things? Okay, but this will be after 8pm my time, as the calls will come out of my pocket and appear on my parents 'phone bill, and its cheaper then, and they'll have to be real short. ***** Fine, I will phone you, if you provide time windows and phone number(s). ***** I will address costs. > **** Our PRECIS/SKETCH and work from it will not address the following things > **** (related to discussion in our group, but not central to it): > **** - the fully portable MPI program I vote we exclude from our discussion. > **** - I/O I vote we exclude from our discussion. > **** - the semantics and syntax of process management Perhaps something of this should be thought about. Quick thoughts/suggestions: * Create new process group (blob of processes :-) * Resize existing process group (shrink/grow blob, synchronously in blob) **** OK, I will think about the proposal X closure matrix placement of this. > **** - the time-table for MPI-1,MPI-2,MPI-3,... I vote we exclude from our discussion. > **** In a truly global sense, these could be construed to be closure as > **** well, but I want to exclude them for sanity reasons. I do believe > **** that parts of these issues could be addressed within MPI-1, but > **** it is not now this subcommittee's role to do that for MPI at-large. > **** Strong objections? If so, we are in deep trouble:-) No objections. > **** > **** We will assume that discussion in this 4-proposal X closure effort is > **** all essential to MPI-1. Anything you really don't think is essential > **** for MPI-1... once we agree to same .... should probably get deferred. > **** Is that controversial? Not controversial. > **** I thank everyone for their sincere efforts. - ditto - > **** PS Per constructive advice from Rik, all of my mail is getting copied to > **** mpi-context now. All should do so. I did not hear any dissent > **** about this suggestion, and it adds potential help to > **** discussion. As we need the help, and few people are writing > **** anyway, this will not likely cause problems. > **** Continue to include the five names jim, lyndon, tony, sanjay & > **** Rik, incase any of us are not on the mpi-context mailing list!!! Concur, being done. > > > **** Rik writes... > > >Before it gets TOO stale, here's a copy of my writeup on static > >contexts et.al. as it last went to Lyndon and Tony. (You two can > >stop reading at the line of dashes.) > > > >I have opted not to hack on static contexts any more because I > >would rather kill them. > **** Is this a proposal to include static contexts as in within > **** the 4-proposal model, and that we stop working on same? > **** If so, I can make it so... I'd like us to now ask Rik to write Proposal II. **** Yes, Rik please do proposal II!!! Best Wishes Lyndon ----- End Included Message ----- **** Best wishes, **** Tony Summary of what went on above: We agreed that Lyndon would do I and Ib (his extension) We requested that Rik would do II (please agree/decline :-) I am still not sure if Rik did/plans to do a precis/sketch merger??? By implication, I am left with III/IV, expecting to get help from Jim, Sanjay, et al on it. I have promised to do the proposal X closure precis/sketch update. - Tony From owner-mpi-context@CS.UTK.EDU Wed Mar 10 12:19:48 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA05037; Wed, 10 Mar 93 12:19:48 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA24634; Wed, 10 Mar 93 12:19:24 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 12:19:22 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA24626; Wed, 10 Mar 93 12:19:20 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 09:14 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA21499; Wed, 10 Mar 93 09:12:13 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA20633; Wed, 10 Mar 93 09:12:10 PST Date: Wed, 10 Mar 93 09:12:10 PST From: d39135@sodium.pnl.gov Subject: Problem: group descriptors & coherency To: d39135@sodium.pnl.gov, tony@Aurora.CS.MsState.Edu Cc: jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu Message-Id: <9303101712.AA20633@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu Here's a problem that applies to all proposals. Groups are dynamic. Group ID's must be reusable unless they are very long or we bound the number of groups that can ever get created. Every reference to a group ID must be interpreted in terms of the current definition. This introduces a coherency problem analogous to shared memory. There are at least a half-dozen solutions to the coherency problem, with wide differences in overhead costs and convenience for the user. Explicit coherency control by the application tends to be cheaper but less convenient than implicit control. ==> I suggest that each proposal include some mechanism for solving the group ID coherency problem, including a discussion of its probable costs. Aside: Coherency of tid's seems like a smaller problem, based on the assumption that processes will come and go much less often than groups will be re-formed. But I'm not sure that we can ignore it. --Rik From owner-mpi-context@CS.UTK.EDU Wed Mar 10 13:18:27 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA06332; Wed, 10 Mar 93 13:18:27 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28066; Wed, 10 Mar 93 13:18:05 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 13:18:04 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28057; Wed, 10 Mar 93 13:18:02 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 10:10 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA22798; Wed, 10 Mar 93 10:08:19 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA20772; Wed, 10 Mar 93 10:08:13 PST Date: Wed, 10 Mar 93 10:08:13 PST From: d39135@sodium.pnl.gov Subject: implementation assumptions To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.edinburgh.ac.uk, mpi-comm@cs.utk.edu, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@Aurora.CS.MsState.Edu Message-Id: <9303101808.AA20772@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu, mpi-comm@cs.utk.edu In a discussion we are having within the contexts subcommittee, Tony Skjellum commented that: > ... I want to make sure that we do > not provide illusory improvements to the standard, while letting other > parts of it exceed ours in the unscalability department, or let > implementations qualify as compliant, whose unscalability disables the > implied scalability of our syntax/semantics... I agree. This is why (I think) proposals should explicitly address performance. If a proposal assumes that the cost of a particular function is irrelevant, it should say that. If a proposal assumes that a particular function is going to be cheap, it should justify that assumption by naming a time/memory price and outlining an implementation that can achieve it. Sometimes the suggested implementation will reveal further assumptions that have wide implications. Ideally, each proposal will eventually evolve a set of bottom-line assumptions that are consistent and believable. These comments are particularly addressed to those of us beating on contexts and groups, where there seem to be lots of subtle interactions. But I am cross-posting them to the whole committee as food for thought... --Rik ("The Skeptic") Littlefield From owner-mpi-context@CS.UTK.EDU Wed Mar 10 13:29:00 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA06699; Wed, 10 Mar 93 13:29:00 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28812; Wed, 10 Mar 93 13:28:44 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 13:28:43 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28804; Wed, 10 Mar 93 13:28:41 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 10:21 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA23065; Wed, 10 Mar 93 10:19:47 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA20875; Wed, 10 Mar 93 10:19:42 PST Date: Wed, 10 Mar 93 10:19:42 PST From: d39135@sodium.pnl.gov Subject: Re: descriptors vs ID's To: jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@aurora.cs.msstate.edu Cc: d39135@sodium.pnl.gov Message-Id: <9303101819.AA20875@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu (This is a resend. Apparently several addresses got fouled up yesterday.) Rik said: > But I argue that the global ID's should NOT be the things that get > passed to the collective comm routines, and possibly not even to the > pt-pt routines. > > Passing a global ID implies some kind of table searching, unless we > put tight bounds on the value ranges so that we can do a simple > indirection. Of course, I suppose I could equally well argue that the cost of such a lookup would be small compared to the overall cost of the collective comm routine. Maybe this is a don't-care. --Rik (Good grief, Lyndon -- replying to one's own mail seems to be catching!) From owner-mpi-context@CS.UTK.EDU Wed Mar 10 13:59:18 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA07404; Wed, 10 Mar 93 13:59:18 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00653; Wed, 10 Mar 93 13:58:49 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 13:58:47 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA00645; Wed, 10 Mar 93 13:58:45 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 10:49 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA23233; Wed, 10 Mar 93 10:47:14 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA21230; Wed, 10 Mar 93 10:47:12 PST Date: Wed, 10 Mar 93 10:47:12 PST From: d39135@sodium.pnl.gov Subject: Re: descriptors vs ID's To: jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@aurora.cs.msstate.edu Message-Id: <9303101847.AA21230@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu (This is a resend with modifications [flagged with **]. The original, yesterday, had fouled up addresses.) Jim raises the issue: > Are the tid's of local or global scope. i.e. Can I pass a tid to > someone else, and it still work as an address for the person I > passed it to ? > For global scope : It's simpler for the user > Against : The implementor might want the "opaque identifier" > to be a pointer to a big data structure containing > route tables or something. The same problem arises with groups and I'm not sure where else. I agree that we need global scope ID's for tids and probably for groups. But I argue that the global ID's should NOT be the things that get passed to the collective comm routines, and possibly not even to the pt-pt routines. Passing a global ID implies some kind of table searching, unless we put tight bounds on the value ranges so that we can do a simple indirection. For tid's, that's OK because there are only as many tid's as there are processes, and I'm willing to believe that's a small bound. But in theory there can be lots more groups than processes, and even in practice I'm not sure that we can keep the global ID's both unique and small without excessive overhead. (E.g., recall my trick of generating unique context values without communication by cramming the creator's process number into the bottom bits.) I propose that most routines be passed a local descriptor reference, rather than the global ID value. ** The above may be don't-care. For collective comms, the cost ** of finding a (local) group descriptor, given the group ID, ** is arguably small compared to the cost of the comm itself. ** For tid's, perhaps the tid values can be kept small enough to ** permit simple indirection. Then we need either 1. routines to retrieve the global ID from a local descriptor (easy) and to construct a local descriptor from the global ID (harder) or 2. a mechanism to translate local descriptors to and from some machine-independent form. I prefer the second option because of my bias against servers. ** In another message, I raised the problem of maintaining ** coherence of group descriptors if the group ID's can be reused. ** The comments above also relate to methods of explicitly ** restoring coherency. Scheme 1 would be used if a process was ** told only "group XX has been redefined, please invalidate your ** descriptor"; scheme 2 would be used if a process was told ** "group XX has been redefined and here's the new definition". --Rik Littlefield From owner-mpi-context@CS.UTK.EDU Wed Mar 10 14:20:17 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA08095; Wed, 10 Mar 93 14:20:17 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01852; Wed, 10 Mar 93 14:19:58 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 14:19:57 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01844; Wed, 10 Mar 93 14:19:56 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 11:14 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA23523; Wed, 10 Mar 93 11:13:08 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA21416; Wed, 10 Mar 93 11:13:06 PST Date: Wed, 10 Mar 93 11:13:06 PST From: d39135@sodium.pnl.gov Subject: Re: [d39135@sodium.pnl.gov: Re: group descriptors] To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, ranka@top.cis.syr.edu, tony@Aurora.CS.MsState.Edu Cc: mpi-context@cs.utk.edu Message-Id: <9303101913.AA21416@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu > So, my basic request to Rik is that he echo the two letters sent to him > alone, which was my error. Mea culpa. I think there was only one, and I included the whole thing in my note referencing it, so it has been echoed already. No problem. --Rik Littlefield From owner-mpi-context@CS.UTK.EDU Wed Mar 10 14:21:50 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA08148; Wed, 10 Mar 93 14:21:50 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01996; Wed, 10 Mar 93 14:21:19 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 14:21:18 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA01988; Wed, 10 Mar 93 14:21:16 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 11:10 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA23493; Wed, 10 Mar 93 11:08:57 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA21333; Wed, 10 Mar 93 11:08:53 PST Date: Wed, 10 Mar 93 11:08:53 PST From: d39135@sodium.pnl.gov Subject: Re: group descriptors To: d39135@sodium.pnl.gov, tony@Aurora.CS.MsState.Edu Cc: jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu Message-Id: <9303101908.AA21333@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu Tony writes > Anyway, I concur on the need to have registerable choices, that allow > sharing, per your letter. As regards new functionality, they could go > in the tree too, but there is no structural mechanism in Zipcode, > other than defining a class' method list, for adding new instantiations > to a mailer at creation. All of this was very elaborate coding, which > I will elucidate in my article for Rolf. I am happy to share details > with you as well, beforehand. Maybe I haven't thought about this enough, but I do not understand why elaborate coding is required if we do everything at runtime and do not try to provide type-safety. No one has yet pointed out a deficiency with my proposed interface: MPI_set_group_attribute (gid,key,value,destructor_routine) and MPI_test_group_attribute (gid,key,&value) This can be implemented at a data cost of adding a single slot to a group descriptor (pointing to the attribute dictionary), plus a loop in the group closing routine to call the destructors (if any), plus the routines to manage the dictionary. I do not believe that there would be much resistance from the committee to adding this capability, since it seems to be easy to implement and (almost) "free if you don't use it". What have I missed? --Rik Littlefield PS. OK, since nobody else has pointed out a deficiency, I will. The definition provided above does not support transferring attributes between processes. The uses that I had in mind involve information that is so local to the process that transferring it doesn't even make sense (e.g., lists of partners for collective comms). If one wanted to define attributes that could be transferred, the interface would have to be extended. From owner-mpi-context@CS.UTK.EDU Wed Mar 10 14:51:58 1993 Received: from CS.UTK.EDU by surfer.EPM.ORNL.GOV (5.61/1.34) id AA08797; Wed, 10 Mar 93 14:51:58 -0500 Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03683; Wed, 10 Mar 93 14:51:06 -0500 X-Resent-To: mpi-context@CS.UTK.EDU ; Wed, 10 Mar 1993 14:51:04 EST Errors-To: owner-mpi-context@CS.UTK.EDU Received: from pnlg.pnl.gov by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03673; Wed, 10 Mar 93 14:51:02 -0500 Received: from carbon.pnl.gov (130.20.188.38) by pnlg.pnl.gov; Wed, 10 Mar 93 11:48 PST Received: from sodium.pnl.gov by carbon.pnl.gov (4.1/SMI-4.1) id AA24208; Wed, 10 Mar 93 11:46:25 PST Received: by sodium.pnl.gov (4.1/SMI-4.0) id AA21672; Wed, 10 Mar 93 11:46:20 PST Date: Wed, 10 Mar 93 11:46:20 PST From: d39135@sodium.pnl.gov Subject: re: static contexts writeup To: d39135@sodium.pnl.gov, jim@meiko.co.uk, lyndon@epcc.ed.ac.uk, mpi-context@cs.utk.edu, ranka@top.cis.syr.edu, tony@Aurora.CS.MsState.Edu Message-Id: <9303101946.AA21672@sodium.pnl.gov> X-Envelope-To: mpi-context@cs.utk.edu Tony, You write > **** In mail immemorial, Rik agreed to merge his (enclosed) write-up with > **** the first-generation PRECIS, to generate a more useful one, > **** Please correct me if I am wrong, but I cannot find this! I think I'm clean. The exchange was > > > (Tony writes) > > > So, my first action item is to get a merger of what you wrote and our > > > precis, and redistribute that to group. OK? > > > > (Rik replies) > > I'm not sure that I've seen your precis yet. The stuff you've sent me > > so far seems to be quite a ways from precise (pardon the pun), so I'm > > reluctant to guess what's what. Can you send me a labeled copy? > > > > It would be faster and perhaps less confusing if I incorporated the > > last round of your and Lyndon's comments into my words and distributed > > that to the subcommittee as a separate document. Then we would have > > a collective op