Subject: Some notes on MPI

From: MPS ENGINEERING 223-4656 <[email-masked]>
Date: Mon, 15 Feb 93 14:43:30 PST

15-FEB-1993

Some general comments from the Massively Parallel Systems Group of
Digital Equipment Corporation on MPI:

The MPI effort must strive to Keep It Simple !!!
The multiple levels idea is good as long as it is clearly
stated what the model is in terms of mixing the use of levels
within an application.

Language independence must be worried about.... C and FORTRAN
are a MUST today, C++, ADA, and others will be of interest in
the future.

MPI must be a reliable message passing system. i.e. The user must not
be burdened with running a protocol on top of MPI to support
retransmission, etc..... (An optional non-reliable mode should
not be ruled out.)

MPI should be thread safe.  All functions should return error codes
not just a fail/succeed status.  All subroutines should have a status 
argument into which an error code can be returned.  Groups and communication
contexts discussions and specifications must include thread usage rules and
guidelines.

When in doubt give the user the choice about buffering and other less
than obvious characteristics.... But, consistently warn about portability
issues WHENEVER a choice is offered.

FLAG ALL CHOICES THAT CAN CAUSE PORTABILITY PROBLEMS !!!
Be particularly careful with the homogeneous vs heterogeneous environment
issues. i.e. Packing verses raw data, XDR etc....  Models / guidelines
should be included to address the issue of sending structures and endian
sensitive data between heterogeneous environments.

When the syntax effort gets serious: All names should be readable, 
descriptive, and consistent.  No numeric constants should exist in the
MPI standard.  All constants should be defined symbolically only !!!
(POSIX inherited a lot of stuff from SVID and should not be use as a
 strict model)
  
Data hiding via opaque types should be used unless there is a truly
justifiable reason.

A message type registration facility should be considered as an alternative
to communication contexts.

---

From: Tony Skjellum <[email-masked]>
Date: Mon, 15 Feb 93 17:54:04 CST

Please elaborate on these points so we can discuss them at the meeting,
in the context subcommitee.
  
>Data hiding via opaque types should be used unless there is a truly
-- what does this mean????

>to communication contexts.

I see "current typing practice without any registration," 
      "current typing practice plus context registration,"
and   "typing registration with no degrees of freedom left for user,"
as the three alternatives.  I think the latter is too restrictive, because
user cannot encode semantically meaningful bits into types at all.  In the
first (current) option, this can be done, but there are big risks of
conflicts in real programs.  Hence, I continue to favor the middle option.

- Tony