<html><body>
<p>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?<br>
<br>
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.<br>
<br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-22-bounces@lists.mpi-forum.org wrote on 03/03/2008 01:24:11 PM:<br>
<br>
> On Mar 3, 2008, at 12:54 PM, Dries Kimpe wrote:<br>
> <br>
> >> Narrowing the scope to "whether translation functionality is <br>
> >> required"<br>
> >> is good. But note that whether the translation functionality is used<br>
> >> may be specific to a given (communicator,peer,datatype) tuple.<br>
> ><br>
> > You're right that this depends on the communicator and on the peer;<br>
> <br>
> ...and the datatype.<br>
> <br>
> > It would not be uncommon to have one 'different (memory representation<br>
> > wise)' node in the communicator. This could be a login node, a<br>
> > visualisation node, ...<br>
> ><br>
> > So, from a performance point of view (and also for the mpi <br>
> > implementation<br>
> > internally), it's actually better to record this information for<br>
> > (communicator, source, dest). However, my main reason for this <br>
> > proposal<br>
> > was to enable an application that doesn't care about datatypes <br>
> > (might be<br>
> > more common than you'd think, looking at some of the mpi-subset <br>
> > ideas) to<br>
> > abort execution if it detects that data conversion is needed when<br>
> > communicating to its peers.<br>
> <br>
> <br>
> My point is that some datatypes may require translation while others <br>
> may not. It's not always just endian differences -- sometimes there's <br>
> floating point representation differences, or size differences (e.g., <br>
> sizeof(int) != sizeof(int)).<br>
> <br>
> -- <br>
> Jeff Squyres<br>
> Cisco Systems<br>
> <br>
> _______________________________________________<br>
> Mpi-22 mailing list<br>
> Mpi-22@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><br>
</tt></body></html>