<div>I have a lot of issues with my legal department on 3rd party code.&nbsp; I jumped through hoops to get approval starting at 1.0.4.&nbsp; Every litle change is the begining of endless paper works and reviews.&nbsp; The approval to use 106 was on conditions that I use only the enahncment and bug fixes in that version.&nbsp; So, I have to stay with what I am approved for.</div>  <div>&nbsp;</div>  <div>For now, I will just write some if..else in my code, and use an external flag to control it.</div>  <div>&nbsp;</div>  <div>tan</div>  <div><BR><BR><B><I>Darius Buntinas &lt;buntinas@mcs.anl.gov&gt;</I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>Hmm. I can't see a way that an MPI implementation could (efficiently <BR>and reliably) check that two virtual addresses from different processes <BR>point to the same location in a shared memory region. An MPI <BR>implementation wouldn't have enough
 information to do what you're asking.<BR><BR>Rusty Lusk mentioned to me that there was a message-passing library <BR>called p4 that would allow this kind of thing. You would allocate a <BR>message using p4_msg_alloc(), then fill the message and send it. The <BR>receiver can receive the message without specifying a destination <BR>buffer. In this case, on a shared memory machine, the receiver gets a <BR>pointer to the original buffer allocated by the sender using <BR>p4_msg_alloc(), and no copy is made.<BR><BR>-d<BR><BR>On 10/09/2007 11:53 AM, chong tan wrote:<BR>&gt; Well, shared-mem and sending 0 byte does not work if the processes are <BR>&gt; on differnt boxes. My thought is that since MPICH already make the <BR>&gt; dicission on wheter to use shared memory. It is a nature fit that the <BR>&gt; 'no copy' rule be applied in that domain.<BR>&gt; <BR>&gt; thanks<BR>&gt; tan<BR>&gt; <BR>&gt; <BR>&gt; */Darius Buntinas <BUNTINAS@MCS.ANL.GOV>/* wrote:<BR>&gt; <BR>&gt;
 <BR>&gt; <BR>&gt; On 10/08/2007 01:38 PM, chong tan wrote:<BR>&gt; &gt; I am interested in the case that the send and recieve buffer are the<BR>&gt; &gt; same buffer allocated from shared-memory, in which case there is<BR>&gt; no need<BR>&gt; &gt; for the data copying, send and recieve just only do the sync.<BR>&gt; <BR>&gt; In this case, why not use a zero-byte message? The sender fills in the<BR>&gt; shared buffer, does a write barrier, then calls MPI_Send with a<BR>&gt; zero-byte message. The receiver calls MPI_Recv, to receive zero bytes,<BR>&gt; then when it returns, it does a read barrier and reads the data from<BR>&gt; the<BR>&gt; shared buffer.<BR>&gt; <BR>&gt; &gt; A side question, when MPI_Send is called, does MPICH copy the<BR>&gt; data into<BR>&gt; &gt; a intermediate global buffer ? and have the data copy from this same<BR>&gt; &gt; buffer on MPI_Recv call ?<BR>&gt; <BR>&gt; It depends on the channel and what you're sending. For non-contiguous<BR>&gt; data,
 the data may be packed into a contiguous buffer before sending<BR>&gt; and<BR>&gt; unpacked from a contiguous buffer when receiving. Otherwise, if a<BR>&gt; channel uses sockets, an intermediate buffer is not used by MPICH2, but<BR>&gt; the OS will perform intermediate copies. For a channel that uses a<BR>&gt; high-performance network, an intermediate buffer is used for small<BR>&gt; messages, but for large messages the data is transferred directly from<BR>&gt; or into the user's buffer.<BR>&gt; <BR>&gt; -d<BR>&gt; <BR>&gt; &gt; tan<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; */Darius Buntinas /* wrote:<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Well, you specify one buffer in the call to MPI_Send and another<BR>&gt; buffer<BR>&gt; &gt; in MPI_Recv, so there would have to be at least one copy. You<BR>&gt; can't do<BR>&gt; &gt; it without any copies (otherwise, how would the data get from the<BR>&gt; send<BR>&gt; &gt; buffer to the receive buffer?).<BR>&gt; &gt;<BR>&gt; &gt; MPICH2
 does support communication over shared memory (as opposed to<BR>&gt; &gt; over<BR>&gt; &gt; a network) which improves performance for intranode communication.<BR>&gt; &gt; Configure with --with-device=ch3:ssm or --with-device=ch3:nemesis.<BR>&gt; &gt;<BR>&gt; &gt; Darius<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; On 10/08/2007 12:22 PM, chong tan wrote:<BR>&gt; &gt; &gt; If I the pointer passed to MPI_Send and MPI_Recieve are already<BR>&gt; &gt; shared<BR>&gt; &gt; &gt; memory, and need not be copied at all ?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; If so, How ?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; thanks<BR>&gt; &gt; &gt; tan<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; ------------------------------------------------------------------------<BR>&gt; &gt; &gt; Be a better Heartthrob. Get better relationship answers<BR>&gt; &gt; &gt; from<BR>&gt; &gt; &gt; someone who knows.<BR>&gt; &gt; &gt; Yahoo! Answers - Check it out.<BR>&gt; &gt;<BR>&gt;
 &gt;<BR>&gt; &gt;<BR>&gt; ------------------------------------------------------------------------<BR>&gt; &gt; Need a vacation? Get great deals to amazing places<BR>&gt; &gt; on<BR>&gt; &gt; Yahoo! Travel.<BR>&gt; <BR>&gt; <BR>&gt; ------------------------------------------------------------------------<BR>&gt; Boardwalk for $500? In 2007? Ha!<BR>&gt; Play Monopoly Here and Now <BR>&gt; <HTTP: evt="48223/*http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow" us.rd.yahoo.com><BR>&gt; (it's updated for today's economy) at Yahoo! Games.<BR><BR></BLOCKQUOTE><BR><p>&#32;

      <hr size=1>Boardwalk for $500? In 2007? Ha! <br><a href="http://us.rd.yahoo.com/evt=48223/*http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow">Play Monopoly Here and Now</a> (it's updated for today's economy) at Yahoo! Games.