Subject: Re: Next MPI meeting

From: L J Clarke <[email-masked]>
Date: Fri, 11 Jun 93 14:53:01 BST

David

Sometimes, I am stupid. Sorry.

I will clean your original example and send later, but later will now
most probably be Monday. 

> 
>    I still think I am right. 

You are right. 

>    More generally, my example will still work for 3 arbitrary
>    groups, provided the two FFT groups are distinct and each is
>    half the size of the third group (which does the product and inverse
>    FFT). For example, if we had N processes, N/4 could work on FFT1,
>    N/4 could work on FFT2, and N/2 could work on the product and
>    inverse FFT. So I could input one array and find its FFT on a bunch
>    of workstations at ORNL, input and do the second FFT on the Delta at
>    Caltech, and each could send its results to EPCC where the product and
>    inverse are done on a transputer array and displayed to a graphical
>    device.

Yup, my stupidity in the extreme, your example was deeper than I first
appreciated. 

>  
>    Well if we're not requiring synchronization (which would amount to
>    another sort of ready mode related to communicators) this discussion
>    is academic (so I'll continue). 

:-)

>    It seems to me that if one subgroup
>    is running on a very faster bunch of processors and the other isn't 
>    then the fast group could whip through its mpi_make_comma and
>    mpi_isendc and get a message to the other group before that group
>    could complete its mpi_make_comma

So why is this a problem? The message can just wait in a queue until the
slow group makes it communicator and does its receive. 

Best Wishes
Lyndon (the sometimes stupid)

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

---

From: James Cownie <[email-masked]>
Date: Fri, 11 Jun 1993 15:04:37 +0100

> slow group makes it communicator and does its receive. 

Indeed, as I remember the discussion at the end of the last meeting,
the conclusion was that insisting on the synchronisation caused
unpleasant problems (especially in Paul Pierce's example), and that we
should allow programs to send messages to other nodes which had not
yet constructed the correct context in which to receive them.

This seems reasonable (though I don't actually like the implementation
implications...). 

The question is what happens to a message which arrives at a node for
a context which does not yet exist at that node ?

The presentation at the last meeting said this was illegal, hence the
need to synchronise. (And the funny synchronisation function on a
group which doesn't yet exist).

After Paul's argument it seemed to be accepted that such messages
should be buffered until the context they could be matched with a
receive (which of course implies the context now exists).

The analogous situation with the tag field would be to allow only the
"ready receiver send"...

-- 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]