<div class="gmail_quote">On Tue, Mar 20, 2012 at 00:06, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div class="gmail_quote">On Sun, Mar 18, 2012 at 11:55, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 Add a glance adding all these new complications to PETSc to chase an impossible overlap of communication and computation sounds fine :-)</blockquote></div><div><br></div></div><div>/Q has a dedicated thread to drive asynchronous comm. I've added this, the call to PetscCommSplitReductionBegin() is entirely optional (does not alter program semantics), but will allow asynchronous progress to be made.</div>

<div><br></div><div>On conventional systems, there are two choices for driving asynchronous progress:</div><div><br></div><div>1. Set the environment variable MPICH_ASYNC_PROGRESS=1. "Setting that environment variable will cause a cheesy form of background progress wherein the library will spawn an additional background thread per MPI process.  You'll have to play around with things, but I'd recommend cutting your number of processes per node in half to avoid nemesis oversubscription badness." -- Dave Goodell</div>

<div><br></div><div>2. Make any nontrivial calls into the MPI stack. This could specifically mean polling a request, but it could also just be your usual communication. I suspect that a standard MatMult() and PCApply() will be enough to drive a significant amount of progress on the reduction.</div>

<br><div><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/d2d98894cb5c" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/d2d98894cb5c</a></div>
</blockquote></div><br><div>And here's some preliminary test output on 32 processes of cg.mcs. I ran a handful of times with src/vec/vec/examples/tests/ex42.c and these results seem reproducible.</div><div><br></div>
<div><div><font face="'courier new', monospace">VecScatterBegin      300 1.0 8.5473e-04 1.5 0.00e+00 0.0 9.6e+03 4.0e+01 0.0e+00  2  0 98 99  0   2  0 98 99  0     0</font></div><div><font face="'courier new', monospace">VecScatterEnd        300 1.0 1.1136e-02 7.6 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 18  0  0  0  0  18  0  0  0  0     0</font></div>
<div><font face="'courier new', monospace">VecReduceArith       100 1.0 1.4210e-04 1.5 9.00e+02 1.0 0.0e+00 0.0e+00 0.0e+00  0100  0  0  0   0100  0  0  0   203</font></div><div><font face="'courier new', monospace">VecReduceComm        100 1.0 2.1405e-02 1.8 0.00e+00 0.0 0.0e+00 0.0e+00 1.0e+02 60  0  0  0 89  60  0  0  0 90     0</font></div>
</div><div><font face="'courier new', monospace"><br></font></div><div><div><font face="'courier new', monospace">VecScatterBegin      300 1.0 5.9962e-04 1.9 0.00e+00 0.0 9.6e+03 4.0e+01 0.0e+00  5  0 98 99  0   5  0 98 99  0     0</font></div>
<div><font face="'courier new', monospace">VecScatterEnd        300 1.0 1.6668e-03 4.3 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 12  0  0  0  0  12  0  0  0  0     0</font></div><div><font face="'courier new', monospace">VecReduceArith       100 1.0 1.1611e-04 2.5 9.00e+02 1.0 0.0e+00 0.0e+00 0.0e+00  1100  0  0  0   1100  0  0  0   248</font></div>
<div><font face="'courier new', monospace">VecReduceBegin       100 1.0 5.3430e-04 2.3 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  4  0  0  0  0   4  0  0  0  0     0</font></div><div><font face="'courier new', monospace">VecReduceEnd         100 1.0 2.4858e-03 2.6 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 21  0  0  0  0  21  0  0  0  0     0</font></div>
</div><div><br></div>