Re: A proposal to change the direction of 1-sided comm

David C. DiNucci (dinucci@nas.nasa.gov)
Fri, 28 Jun 1996 11:40:02 -0700

Greg Burns wrote:
>
> >From: Jarek Nieplocha <j_nieplocha@pnl.gov>
> >
> >To realize the problem, please imagine a class of producer-consumer
> >algorithms executed by processes A and B with the items produced/consumed
> >in the window of process C (which is executing some other subtask
> >and is unaware of the 1-sided coms targeting its window).
> >[I tried to post this example before but my message was probably lost -
> >I am on travel in Europe with limited access to Internet]
>
> OK, I realize the problem. Now please explain why this third party
> technique is the only or clearly superior method of programming
> some applications in your field.
>
> Yes, my shared memory programming experience is weak. Somehow, I thought
> I wouldn't need it while working on Message-Passing Interface.
> The only example I understand is the random-access requirement of building
> up a matrix in some chemistry codes. You do a lot of puts and then
> do a barrier. We have a high proportion of chemistry users at OSC
> so I know they will be happy to have this functionality. I had a
> graphics application of my own where random-access gets were required.

This functionality will be in MPI, no matter which of the current options is
voted in. The only debate on this is which approaches are (1) easier to
understand, and (2) more efficient in the sense that more processors can keep
busy doing useful work.

> Why are people proposing radical changes to a chapter that has already
> passed the first formal vote? Could it be that there is a profound
> lack of confidence in what we are doing? I understand the vote was 13-7-5.

I did some analysis of the current proposal last weekend (prompted by a remark
from Eric Salo), and found that some parts of chapter 4 did not seem well defined.
Requests for clarification did not seem to be fruitful. So, after removing the
problem parts (i.e. WINDOW_IN, WINDOW_OUT, FENCE, and counters), the rest of the
proposal was simplified. This was called the Barrier-based model. Then I
simplified it some more to make GET and PUT collective operations. Both of these
proposals will handle your problems, above, without WINDOW_IN, WINDOW_OUT, FENCE,
or counters. Some people seem to be objecting to the collective operations, even
though I assert that they are *at least*, and in some cases, *more* efficient and
easier to understand than the barrier-based one.

However, both of these leave some functionality out -- specifically, how to just
have two (or a few) processes in a communicator performing GET and PUT, and/or
performing operations through a third process (similar to what Jarek is
addressing). I proposed one solution (see "Extended Proposal: pt2pt 1-sided"),
Marc proposed another just now, and others are considering others. There are a
few other issues, too, such as whether the target process is required to leave
its entire address space open to GETs and PUTs, or whether it can restrict the
portions visible/modifiable by other processes. (For the record -- I'm on the
side of restriction.) Nothing else too important.

-Dave
(The history according to Dave.)

-- 
===============================================================================
David C. DiNucci    | MRJ, Inc., Rsrch Scntst  |USMail: NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)|        M/S T27A-2
(415)604-4430       | Parallel Tools Group     |        Moffett Field, CA 94035