> On May 29, 2015, at 2:29 PM, Jed Brown <[email protected]> wrote: > > Barry Smith <[email protected]> writes: > >> I cannot explain why the load balance would be 1.0 unless, by >> unlikely coincidence on the 248 different calls to the function >> different processes are the ones waiting so that the sum of the >> waits on different processes matches over the 248 calls. Possible >> but > > Uh, it's the same reason VecNorm often shows significant load imbalance.
Uh, I don't understand. It shows NO imbalance but huge times. Normally I would expect a large imbalance and huge times. So I cannot explain why it has no imbalance. 1.0 means no imbalance. > >>> I've added a barrier in the code. >> >> You don't need a barrier. If you do not have a barrier you should >> see all the "wait time" now accumulate somewhere later in the code >> at the next reduction after the VecAssemblyBegin/End. > > Presumably he added a barrier *before* calling the function. The > function does a small amount of work (basically none because he has no > off-process entries) and synchronizes (PetscMaxSum). If there was load > imbalance before calling VecAssemblyBegin, the timer would start at > different times on each process, but end at about the same time. Yes, but then it would show a large imbalance, while it in fact shows no imbalance.
