> ..... My position was that byte alignment put/get -s can be
> done on those systems but the 1-sided communication for alignments not
> supported in hardware would become 2-sided operations very similar to
> simply doing an MPI_Send. A limitation that put/get -s are allowed only
> on certain boundaries would be fine with me but I think that since misaligned
> messages are allowed, it is possible to at least simulate misaligned put/get -s
> on systems that don't allow certain alignments.
(1) At least to me, "1-sided" and "2-sided" (aka point-to-point) are descriptions
of semantics rather than implementation. They are defined by the routines
that the user calls and the effects of those routines, rather than how the
hardware implements them.
(2) As you mention and from some of the descriptions I've read here, it seems
that some systems can perform almost any kind of remote operation without
involving the remote CPU. On the other hand, lots of systems cannot perform
any remote operation without involving the remote CPU. It's clear that, at
some point, the question must be "what functionality do programmers desire
from one-sided communication" rather than "what one-sided communication can
be implemented without involving the remote processor. One way to combine
the answers to these two questions is to provide the functionality in
pieces. If almost any machine can do X efficiently, and some machines can
additionally do some useful Y efficiently, then offer X, Y, and Z=X+Y.
Programmers who want efficiency will strive to use just X, but if they need
to do both X and Y, they will use Z and allow some architectures to use
their special powers. (Maybe in this case "X" is an aligned communication
and "Y" is a copy to an unaligned location, so "Z" is an unaligned
communication.)
(3) One question that has also been asked is -- "what one-sided communication can
be implemented without involving the remote *process*". Again, some
combinations of OS and architecture (what we used to call "virtual machines",
before PVM came along) will allow a fairly efficient implementation of a
model where a process can feel the effects of a remote "put" anywhere in
their address space in a timely manner without executing any extra commands.
I believe that this is not possible on many other machines. Specifically,
I believe that the only method of writing into the address space of another
process in Unix is mmap, and I don't know how standard this is or whether
coherence is always assured. Cache coherence and other architectural
decisions may also come into play.
(4) Whether or not it is *possible* or *efficient* to implement 1-sided which
does not require involvement of the remote process, involvement is often
desired for *correctness*. If process P puts to process Q, process Q will
often want to ensure, somehow, that the transfer has completed before it
accesses the new value. In some cases and on some architectures, it may be
able to spin waiting for some "sentinel" value to be put somewhere,
effectively implementing a spin-lock in high-level code -- not exactly
desirable. It would be much more desirable for the model to offer some
standard way of waiting for a specific put to complete. (Of course, there
may be times when you don't need this extra functionality, but it is
often important.)
Putting all of these together, I personally don't think that a communication
model suffers much by requiring that a remote process execute some command
before it can expect that data from a remote put is available. It makes the
model much more portable, and on fancy systems with lots of hardware that
does all the dirty work, the user command might not need to do much (and maybe
can even be implemented as a noop).
Similar arguments can be made for specifying each piece of data that must be
"gettable" by another process.
-- =============================================================================== 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