The simple question seems to be: Can MPI_BYTE be used safely on this communicator? If even one datatype requires translation then the answer is "no". How about just calling the per communicator attribute something like "MPI_BYTE_SAFE" and leave other debates about the meaning of heterogeneous aside?

There is clearly room to add complexity but is there a real need? It seems to me that communicator attribute "MPI_BYTE_SAFE" provides 99% of the value and is easy to do.


Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363


mpi-22-bounces@lists.mpi-forum.org wrote on 03/03/2008 01:24:11 PM:

> On Mar 3, 2008, at 12:54 PM, Dries Kimpe wrote:
>
> >> Narrowing the scope to "whether translation functionality is  
> >> required"
> >> is good.  But note that whether the translation functionality is used
> >> may be specific to a given (communicator,peer,datatype) tuple.
> >
> > You're right that this depends on the communicator and on the peer;
>
> ...and the datatype.
>
> > It would not be uncommon to have one 'different (memory representation
> > wise)' node in the communicator. This could be a login node, a
> > visualisation node, ...
> >
> > So, from a performance point of view (and also for the mpi  
> > implementation
> > internally), it's actually better to record this information for
> > (communicator, source, dest). However, my main reason for this  
> > proposal
> > was to enable an application that doesn't care about datatypes  
> > (might be
> > more common than you'd think, looking at some of the mpi-subset  
> > ideas) to
> > abort execution if it detects that data conversion is needed when
> > communicating to its peers.
>
>
> My point is that some datatypes may require translation while others  
> may not.  It's not always just endian differences -- sometimes there's  
> floating point representation differences, or size differences (e.g.,  
> sizeof(int) != sizeof(int)).
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> Mpi-22 mailing list
> Mpi-22@lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22