Re: [mpi-21] Proposal EH2: add const keyword to the C bindings

[Dries Kimpe <Dries.Kimpe@xxxxxxxxxxxxxx>]

* Richard Treumann <treumann@xxxxxxxxxx> [2008-01-09 18:16:29]:
> If the "subset of processes within a communicator" is reasonably stable you
> can do better by making an additional communicator containing only those
> processes and doing MPI_Bcast on this subset communicator. If the subset
> keeps changing then making the subset communicator may be too costly
> compared to the savings.

Everybody keeps assuming *exactly* the same buffer is sent to the other
ranks; What if you're sending different parts of the same datastructure to
different ranks, but some of the parts overlap?

A common 'pattern' to do this is to create the datatypes, and a mapping
of (rank,datatype). Then do Isend for every rank,datatype and waitall at
the end.

Why not use alltoall/scatter? Well, if every rank is only communicating to
a limited (non-growing with universe size) number of other ranks, using
collectives serializes the transfer. (nonblocking collectives? ;-)

Although I wouldn't have the user program read from a in-use send buffer,
I for sure am a sinner by having implemented the above described scheme.

I coincide with Gregor:
- I've done this, and by consequence am among those (few??) that do write
  wrong MPI programs.
- The program ran(and runs) without problems on 3 different architectures
  and at least 4 different MPI implementations.
- Not being able to do this forces me to copy every time and reduces
  performance 

Maybe it is reasonable to allow the case of using the send buffer multiple
times, but not allowing the user program to touch it?  This wouldn't
prohibit byte-swapping tricks, and if there is an MPI implementation that
has severe restrictions on send buffers, it might do a little bit extra
bookkeeping (if it doesn't do it already) and handle the case of
overlapping send buffers... 

Implementations that don't care (most current implementations it seems)
won't need to do anything special.

  Greetings,
  Dries


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm