Subject: PT2PT draft (MARCH 23)

From: [email-masked] (James Cownie)
Date: Thu, 25 Mar 93 17:40:59 GMT

Marc,

[This is a reconstruction from memory of some mail I sent this
morning, which seems to have disappeared... If anyone got the original
they can test how good my memory is by comparing the two mails :-)]

Here are some comments and queries on the current (23 March) point to
point proposal.

To avoid duplication of lots of text I will reference the proposal bye
page number. Apologies to those of you who haven't printed it !

Page 3 : Discussion of options for Lists of Handles

My preference is for option 3 (A separate length parameter).

I prefer this over 1 (length as first element) because this leads to
off by one errors, or a funny structure in C with an arbitrary sized
array.

I prefer it over 2 (a delimited list) because it avoids a whole pass
over the list to work out its length when this is required. (e.g. if a
copy needs to be made. cf the horrible C code
     
     char * copy = strcpy(malloc(strlen(string)+1), string);

which accesses every byte of the string twice)

Page 4: Discussion of named constants in FORTRAN.

The F90 discussion should mention MODULEs (e.g. "... can be made
available via an INCLUDE file, or MODULE.")

PLEASE PLEASE PLEASE don't use character strings. This is guaranteed
to be slow. I'd rather have literal values in place than strings !

Page 8 et seq: Contexts.

I don't understand how to implement your context model in the way you
seem to be describing.

On page 8 you suggest that you can check the context at transmission,
and avoid a collective agreement alogrothm at context creation.
Similarly on page 10 in the implementation note you say "No
communication is needed to create a new context beyond a barrier
synchronisation".

Surely you MUST check the context at the receiver (you seemed to agree
with this in previous mail in MPI-context), therefore the sender and
receiver must agree on the context name. (Or at least the sender must
know the value by which the context is known at the receiver, which
could be different for each receiver if you like [I don't !])

To achive this surely you need a group co-operation on context
creation.

Consider

		Process number 
		i.e. Rank in ALL
		0           1	        
Group 0		0           1
Group 1		1	    0

The number in the table is the rank of the process in the group.

Certainly when process 1 receives a message from zero he must know the
group/context from which it was sent, since the result of the sender
inquiry will be different depending on the group/context.

Even if you only allow partitioning, I don't think you can avoid
needing a cooperation, consider a scenario like this

		Process number

Time	0	0     1     2
Time    1       0  |  1     2       Partition of all 
Time    2             1  |  2       Partition of subgroup
Time    3       0     1  |  2       Partition of all

Where the | denotes a partition of the group.
Now with only a sequnce number process 0 has has been involved in 2
partitions, but process 1 (which should be in the same group) has been
involved in 3.

Ah, you can get the right answer by using a count of the partitions of
the the parent group, and its depth in the tree. (Somehow...)

Anyway it all falls apart when you let in the group construction by
list (I believe) !

Page 12:

I agree that we shouldn't REQUIRE dynamic process creation.

Page 13:

A global errno is the CLASSIC example of global data which gives
threads a problem. Do we REALLY want to do it like this ?

Page 14: Data types

I think we should have both MPI_CHAR and MPI_BYTE. The difference
being that in a heterogeneous environment MPI_CHAR would be translated
according to the local character sets (e.g. ASCII -> EBCDIC), MPI_BYTE
would be an 8 bit integer.

What should we do about Fortran 90 KINDs ?

Page 15: Data buffers.
Vector buffer : Do we allow a zero or negative inter block stride ?
Zero is a neat way to perform a fill operation...

Page 17: Last line on the page...

What is the (4,2,1) ? It's not Fortran 77. Looks a bit like an F90
array constructor ...

Page 18: Data conversion
You state "No data conversion occurs when data is moved from a sender
buffer into a message". In a heterogeneous environment surely this is
an implementation issue. The implementation should be free to
translate at source, at dest, or on the moon if it likes.

Page 36: 
You should delete "out of either process' address space." The example
only requires buffering, it doesn't matter where the implementation
chooses to do it.

General question
================
Where is the store which is referenced by handles allocated ? At
present it appears that all of this (even for ephemeral objects) is
MPI system managed. I would very much like it to be possible to have
the user manage this store, as she can often do it cheaper. (e.g.
allocating ephemeral objects on the stack).

Hmmm... came out more or less the same I think.

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