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.