<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 3:29 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
<br>
>   I cannot explain why the load balance would be 1.0 unless, by<br>
>   unlikely coincidence on the 248 different calls to the function<br>
>   different processes are the ones waiting so that the sum of the<br>
>   waits on different processes matches over the 248 calls. Possible<br>
>   but<br>
<br>
</span>Uh, it's the same reason VecNorm often shows significant load imbalance.<br>
<span class=""><br>
>> I've added a barrier in the code.<br>
><br>
>    You don't need a barrier.  If you do not have a barrier you should<br>
>    see all the "wait time" now accumulate somewhere later in the code<br>
>    at the next reduction after the VecAssemblyBegin/End.<br>
<br>
</span>Presumably he added a barrier *before* calling the function.  The<br>
function does a small amount of work (basically none because he has no<br>
off-process entries) and synchronizes (PetscMaxSum).  If there was load<br>
imbalance before calling VecAssemblyBegin, the timer would start at<br>
different times on each process, but end at about the same time.<br></blockquote><div><br></div><div>Yea, I realized that VecAssembly should see this load imbalance unless it had a barrier before its timer.  So I'm not sure what is going on.</div><div> </div></div><br></div></div>