> >>
> >> Puts are required for active messages, in which many people in this group
> >> (myself included) are very interested.
From: Marc Snir <snir@snir.watson.ibm.com>:
> I don't understand this statement. I know a fair number of systems that sup
> port active messages but do not support puts, and vice-versa. In any case,
> the issue is not what are the basic communication mechanisms on the underlying
> machine, the issue is what is made visible by MPI to the user. We can decide
> to provide an active message interface, we can decide to provide a put/get
> interface, we can decide to provide both. Implementers may, at their
> convenience, use one to implemente the other.
Marc,
The Active Message package from Berkeley, that provides run-time support for
the Split C compiler, now comes with put and get functionality in addition to
the regular active messages.
I also have a few comments to your statement that one mechanism can be used to
implement the other.
Neglecting performance issues, active messages as a mechanism more general than
put/get could be certainly used to implement get/put interface. On the other
hand, an attempt to implement active messages with put/get alone could be quite
entertaining.
I believe that the need for active messages in addition to put/get arises from
the fact that put and get are not the only form of remote access that
people need. For example, in case of chemistry codes that we support at PNL,
we have scatter/gather, atomic daxpy-like operation, atomic read-and-increment
in additional to regular gets/puts. Although, all of these operations could be
implemented with put/get in addition to some atomic operation (like defined in
your proposal), on certain platforms the hrecv/AM implementation could be faster.
This might sound controversial, concerning how much performance of interrupt-
receive deteriorated on some recent parallel machines ;-) however, I can provide
specific examples.
One might argue that if we have hrecv/AM as powerful mechanisms to implement
other forms of remote access, gets/puts are not needed. The reason why get/put
in addition to RPC are still useful is that on some shared/global memory
platforms (like SGI or T3D) get/put could be implemented with extremely low
overhead as comparing to cost of hrecv/AM. Thus, for the performance purpose,
we should have interfaces to both.
--Jarek Nieplocha