Subject: interrupt driven

From: L J Clarke <[email-masked]>
Date: Tue, 6 Apr 93 18:28:33 BST

Dear MPI Colleagues

We have, reasonably in my opinion, decided not to provide interrupt
driven receive/send (as in Intel hrecv/hsend) in MPI, or active
messages. 

I have heard, can't recall from whom, that this carries the consequence
that we should not define any feature of MPI which asks for the
implementor of MPI to make use of interrupt driven receives, or active
messages. This seems to me to be a bogus argument.

In my mind the primary reason for not providing hrecv/hsend type
facilities is that it is very difficult to standardise these facilities
across different operating systems, particularly in terms of what the
handler procedure is and is not allowed to do (e.g., can it do I/O, can
it use MPI, ...).  It seems to me clear that on many (all) machines of
interest the system itself will be making use of similar facilities. 
Who would write MPI for CM-5 without using active messages? It seems to
me that for example non blocking communications really do ask for use of
interrupt/active messages. 

Is there agreement, disagreement, or what on this point? Please do let
me know. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: [email-masked]
Date: Wed, 7 Apr 93 10:46:26 PDT

> messages. This seems to me to be a bogus argument.

I (Rik Littlefield) have regularly made arguments that are 
close enough to this to be worth clarifying or defending.

Think of the MPI specification as being divided into two parts:

  1) things you can implement with portable code, and
  2) things you can't.

My bias is to make the POTENTIALLY portable part of MPI as large as 
possible.  (I emphasize "potentially" to make it clear that I am
talking about interface definitions.  I encourage implementors to
do whatever they want internally.)

As an example, consider groups and collective communication.

All other factors being equal, I would strongly prefer a specification
that permitted groups and collective communication, including group
formation and disbanding, to be implemented using just the
standardized MPI point-to-point capabilities.

This sort of layerability potentially has several good effects.  Three
of these are 1) earlier widespread availability via porting, 2) better
focusing of vendor effort on tuning the point-to-point layer, and 3)
the capability to create portable MPI-plug-compatible implementations
that are tuned for different requirements, e.g., debugging versus
performance.

Of course, all other factors are not equal.  Strict layerability also
has some potentially bad effects.  Two of these (depending on where
you draw the line between layers) are 1) the loss of integrated syntax
(e.g., being able to use rank directly in the point-to-point calls),
and 2) loss of functionality that is not supported by lower layers
(e.g., asynchronous name servers).

Whether the good outweighs the bad is a matter of opinion.  

The applications that I deal with now and anticipate dealing with over
the lifetime of MPI-1 can be characterized as follows:

  . sensitive to performance, 
  . intended to run on lots of platforms,
  . not sensitive to syntax, and
  . not needing name server support.

Applications like these are best served by layerability.
Others' mileage may differ.

> Is there agreement, disagreement, or what on this point? Please do let

I agree that it is important to distinguish between exporting a
standardized hrecv/hsend and and exporting a standardized asynchronous
name server interface.  The former seems hopeless; the latter is
doable, but at the cost of potentially detracting from other features
such as performance and prompt widespread availability.

Thus, I do not agree that it is bogus to argue against requiring
asynchronous servers et.al. in MPI-1.

--Rik

----------------------------------------------------------------------
[email-masked] (alias 'd39135')   Rik Littlefield
Tel: 509-375-3927                         Pacific Northwest Lab, MS K1-87
Fax: 509-375-6631                         P.O.Box 999, Richland, WA  99352