<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 7, 2016 at 10:30 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
>     There is still something wonky here, whether it is the MPI implementation or how PETSc handles the assembly. Without any values that need to be communicated it is unacceptably that these calls take so long. If we understood __exactly__ why the performance suddenly drops so dramatically we could perhaps fix it. I do not understand why.<br>
<br>
</span>I guess it's worth timing.  If they don't have MPI_Reduce_scatter_block<br>
then it falls back to a big MPI_Allreduce.  After that, it's all<br>
point-to-point messaging that shouldn't suck and there actually<br>
shouldn't be anything to send or receive anyway.  The BTS implementation<br>
should be much smarter and literally reduces to a barrier in this case.<br></blockquote><div><br></div><div>Hi Jed,</div><div><br></div><div>How to use the BTS implementation for Vec. For mat, we may just use "-matstash_bts"?</div><div><br></div><div>Fande,</div><div> </div></div><br></div></div>