Subject: mpi

From: [email-masked] (James Cownie)
Date: Tue, 19 Jan 93 16:36:37 GMT

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: [email-masked] or [email-masked]