<div dir="ltr">I don't need your branch because 1) we are not doing any communication in this VecAssembly and I added the IGNORE stuff just to make sure and 2) we are catching load imbalance from another part of the code, I am now sure.  I can now see that VecAssemblyBegin's timers do not report this type of load imbalance because it starts with a synch.  This is what I suspected but I was wondering why the timers did not report this load imbalance.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 11:12 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
<br>
> Thanks, this code does not have any communication in VecAssembly so I added<br>
> the INGNORE stuff and added a barrier before this section of code.  I am<br>
> suspecting that VecAssembly is catching load imbalance but not reporting it<br>
> for some reason.<br>
<br>
</span>If you put a barrier before, it starts at about the same time on all<br>
processes.  The operation contains synchronization followed by<br>
(scalable) point-to-point messaging.  The slowness is almost certainly<br>
caused by the non-scalable algorithm -- I've seen it with other<br>
applications.  So try my branch.<br>
</blockquote></div><br></div>