Which MPI implementation for MPI-2? ...
tony at mpi-softtech.com
Thu Apr 3 10:45:58 EST 2003
Our experience in ChaMPIon/Pro is that we get higher latency and higher
bandwidth than 2-sided, vs. the design target of lower latency and lower
bandwidth; the standard missed the mark, but it is still useful.
On Thu, 3 Apr 2003, Richard Walsh wrote:
> On Thu Apr 3 03:43:24 2003 Greg Lindahl wrote:
> >On Wed, Apr 02, 2003 at 02:11:20PM -0600, Richard Walsh wrote:
> >> Somewhat tangentially, but while we are on the subject of one-sided
> >> communications in MPI-2, am I correct in assuming that this capability
> >> is implemented as it is in SHMEM ...
> >No. It's much more complicated and general. You have to register
> >windows within which one-sided ops can be used, and there are some
> >extra calls that you make to make sure operations have completed.
> I see ... then I should also anticipate some loss of performance
> (higher latency) when using one-sided MPI communications compared
> to SHMEM. Or perhaps this is one-time overhead paid at registration
> >UPC is a much more compact method of expressing one-sided calls, and
> >unlike shmem, it can benefit from pipelined transfers.
> Right (so also with CAF) for messages, but you still have to explicitly
> sychronize/lock, etc.
> >> It would seem to be a requirement for speed and would
> >> also seem to require the use of identical binaries on each processor
> >> (and COMMON or static to place data in a symmetric location).
> >shmem doesn't require that; you can use a common address (I'm very
> >punny at 1am) to exchange addresses of malloc-ed data. But with shmem,
> >you get a free registration of all static & common variables, and the
> >stack too, as long as you use it in a consistant fashion.
> As far as I know, SHMEM requires a known address either explicitly
> passed (asymmetric location) between partners or a implicitly determined
> from the symmetry relationships of the images communicating (static
> or common). As you say, this is "free" for COMMON/STATIC data.
> Perhaps we are actually agreeing ... explicitly exchange addresses
> of malloc-ed locations in different binaries would be fine.
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Anthony Skjellum PhD, CTO | MPI Software Technology, Inc.
101 South Lafayette St, Ste. 33 | Starkville, MS 39759, USA
Ph: +1-(662)320-4300 x15 | FAX: +1-(662)320-4301
http://www.mpi-softtech.com | tony at mpi-softtech.com
Middleware that's hard at work for you and your enterprise.(SM)
The information contained in this communication may be confidential and is
intended only for the use of the recipient(s) named above. If the reader of
this communication is not the intended recipient(s), you are hereby notified
that any dissemination, distribution, or copying of this communication, or
any of its contents, is strictly prohibited. If you are not a named
recipient or received this communication by mistake, please notify the sender
and delete the communication and all copies of it.
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf