Subject: A few more ramblings

From: [email-masked] (Tom Henderson)
Date: Tue, 30 Mar 93 09:34:39 MST

Mark,

I had a few more thoughts about Proposal VIII...  

One of the arguments that was unresolved at the last meeting was whether 
contexts should be a "scarce" or "plentiful" resource.  One concern was a 
situation like one we have dealt with here.  One of my co-workers (Bernardo 
Rodriguez) has developed a high-level library for finite difference 
approximation (FDA) problems (common with the weather forecast models we are 
working with).  One well-known strategy for getting decent performance from a 
data-parallel FDA is to compute boundary values, start non-blocking boundary 
exchange, compute interior values while exchange is happening, and complete 
the exchange.  An example of how this code looks with contexts is shown below.  
Routines that start with "LIB" are our "third-party" library routines.  
Routines written by a user of the library start with "USER".  Array "A" 
contains the data.  "myContext" is the context used by the LIB_XXX() 
routines.  

  USER_COMPUTE_BOUNDARY(A, ...)
  LIB_START_EXCHANGE(A, myContext)
  USER_COMPUTE_BOUNDARY(A, ...)
  LIB_END_EXCHANGE(A, myContext)

Unfortunately, weather models have lots and lots of arrays (A, B, C, ...).  If 
we use the same idea we need contexts "myContextA", "myContextB", ...  The 
code looks like:  

  USER_COMPUTE_BOUNDARY(A, B, C, ...)
  LIB_START_EXCHANGE(A, myContextA)
  LIB_START_EXCHANGE(B, myContextB)
  LIB_START_EXCHANGE(C, myContextC)
  ...
  USER_COMPUTE_BOUNDARY(A, B, C,  ...)
  LIB_END_EXCHANGE(A, myContextA)
  LIB_END_EXCHANGE(B, myContextB)
  LIB_END_EXCHANGE(C, myContextC)
  ...

Here's a situation where a "large number" of contexts might be needed.  

Now, here's how we fix it when contexts are scarce:  

  USER_COMPUTE_BOUNDARY(A, B, C, ...)
  LIB_START_EXCHANGE(A, myContext, keyA)
  LIB_START_EXCHANGE(B, myContext, keyB)
  LIB_START_EXCHANGE(C, myContext, keyC)
  ...
  USER_COMPUTE_BOUNDARY(A, B, C,  ...)
  LIB_END_EXCHANGE(A, myContext, keyA)
  LIB_END_EXCHANGE(B, myContext, keyB)
  LIB_END_EXCHANGE(C, myContext, keyC)
  ...

The "keys" are defined by the library to be in some range.  The library 
guarantees that communication operations initiated by calls to any routines 
using different keys will not collide.  This might be done by using "key" 
inside each routine as a base to select a range of tags.  It is the user's 
responsibility to ensure that the "keys" are unique.  

The bottom line is:  the library developer is responsible for managing tags 
used by a library.  The context insures that communication internal to a 
library routine will not collide with communication external to that routine.  

OK, now I'm comfortable with "context" as a scarce resource that is allocated 
ONCE at the beginning of an application.  

Comments?  Flames?  

Tom

---

From: Tony Skjellum <[email-masked]>
Date: Tue, 30 Mar 93 12:30:38 CST

Given all the discussion since I left for Salishamn, I will need to
rely on Mark to present his part of XIII  (oops, VIII) tomorrow.
- Tony