<div>I do run into situation that I exchange few hundred K bytes of data between processes each time they exchange data. WIth sharedmem or nemesis, these means 2 copy operations, from sender to sharedmem to reciever. The idea solution is to have, say, sender being sharedmem, and MPICH use it directly, saving 1 copy operation.</div> <div> </div> <div>having both sender and reciever being the same shared memory may require Barriers to be placed to block writing to the mem before it is completed consumed. That may actually slow done the run.</div> <div> </div> <div>tan</div> <div> </div> <div><BR><B><I>Darius Buntinas <buntinas@mcs.anl.gov></I></B> wrote:</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>Yeah, interesting. But you have to read the maps file every time you do <BR>a send or receive. You can't just read the maps file once at init and <BR>cache it,
because the user could change the mapping after init.<BR><BR>I guess for sufficiently large messages the benefit of not having to <BR>copy would outweigh the cost of reading the maps file.<BR><BR>It may be an interesting study.<BR><BR>-d<BR><BR>On 10/09/2007 02:54 PM, Jean-Marc Saffroy wrote:<BR>> On Tue, 9 Oct 2007, Darius Buntinas wrote:<BR>> <BR>>> Hmm. I can't see a way that an MPI implementation could (efficiently <BR>>> and reliably) check that two virtual addresses from different <BR>>> processes point to the same location in a shared memory region. An <BR>>> MPI implementation wouldn't have enough information to do what you're <BR>>> asking.<BR>> <BR>> It could very well have this information from the operating system.<BR>> On Linux, /proc/self/maps has all the required details.<BR>> <BR>> <BR><BR></BLOCKQUOTE><BR><p> 
<hr size=1> <a href="http://us.rd.yahoo.com/evt=51201/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3MtbmV3Y2Fy
">Check out </a> the hottest 2008 models today at Yahoo! Autos.