<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV><BR></DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">we just completed 1 partiticular tests using SERIALIZED, and that make no difference (compared to</DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">MULTIPLE). </DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt"> </DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">I also check ANY_TAG, we are not using that anymore. SO, we use both source and tag. Given</DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">that there are only 3 producers , N^2 algorithm does not worry me.</DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt"> </DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">tan</DIV>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt"><BR> </DIV>
<DIV style="FONT-FAMILY: arial, helvetica, sans-serif; FONT-SIZE: 13px"><FONT size=2 face=Tahoma>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Pavan Balaji <balaji@mcs.anl.gov><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> mpich-discuss@mcs.anl.gov<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, July 28, 2009 3:09:18 PM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [mpich-discuss] thread MPI calls<BR></FONT><BR><BR>> yes, we are using source, but we are using ANY_TAG. We can't try ANY_SOURCE as<BR>> source is significant, unless I make chanages to the data package.<BR><BR>I'd suggest that you either use both ANY_SOURCE and ANY_TAG, or neither. From an MPI implementation's perspective, always using ANY_SOURCE + ANY_TAG is best for performance, since all incoming messages will have a constant queue search time. On the other hand, if you don't use either of them, then it'll allow the MPI implementation to use multiple queues instead of a single queue, which reduces the search time quite a
bit as well (constant time in most cases as well). Using one of them as a wild-card and the other as a non-wild-card is the worst-case scenario.<BR><BR>> We can try SERIALIZED, but that will block our next strategy which requires MULTIPLE.<BR><BR>For now, this will at least tell us whether MPI's locks are the bottleneck or if there's some other bottleneck.<BR><BR>If this does show up as a problem, we can try to profile your application with MPE and/or rlog (MPICH2's internal profiling tool). It'll give you a nice graphical output on the amount of time spent in each routine. Very useful for performance debugging.<BR><BR>-- Pavan<BR><BR>-- Pavan Balaji<BR>http://www.mcs.anl.gov/~balaji<BR></DIV></div><br>
</body></html>