<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 10, 2016 at 8:12 AM, Xiangdong <span dir="ltr"><<a href="mailto:epscodes@gmail.com" target="_blank">epscodes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 8, 2016 at 6:45 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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Xiangdong <<a href="mailto:epscodes@gmail.com" target="_blank">epscodes@gmail.com</a>> writes:<br>
<br>
> iii) since the time ratios of VecDot (2.5) and MatMult (1.5) are still<br>
> high, I rerun the program with ipm module. The IPM summary is here:<br>
> <a href="https://drive.google.com/file/d/0BxEfb1tasJxhYXI0VkV0cjlLWUU/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/d/0BxEfb1tasJxhYXI0VkV0cjlLWUU/view?usp=sharing</a>.<br>
> From this IPM reuslts, MPI_Allreduce takes 74% of MPI time. The<br>
> communication by task figure (1st figure in p4) in above link showed that<br>
> it is not well-balanced. Is this related to the hardware and network (which<br>
> the users cannot control) or can I do something on my codes to improve?<br>
<br>
</span>Here are a few functions that don't have any communication, but still<br>
have significant load imbalance.<br>
<span><br>
  VecAXPY          1021815 1.0 2.2148e+01 2.1 1.89e+10 1.1 0.0e+00 0.0e+00 0.0e+00  2  4  0  0  0   2  4  0  0  0 207057<br>
</span><span>  VecMAXPY          613089 1.0 1.3276e+01 2.2 2.27e+10 1.1 0.0e+00 0.0e+00 0.0e+00  1  4  0  0  0   1  4  0  0  0 414499<br>
</span><span>  MatSOR            818390 1.0 1.9608e+02 1.5 2.00e+11 1.1 0.0e+00 0.0e+00 0.0e+00 22 40  0  0  0  22 40  0  0  0 247472<br>
<br></span></blockquote><div><br></div><div>The result above is from a run with 256 cores (16 nodes * 16 cores/node). I did another run with 64 nodes * 4 cores/node. Now these functions are much better balanced ( a factor of 1.2-1.3, instead of 1.5-2.1).</div><div><br></div><div>VecAXPY           987215 1.0 6.8469e+00 1.3 1.82e+10 1.1 0.0e+00 0.0e+00 0.0e+00  1  4  0  0  0   1  4  0  0  0 647096<br></div><div>VecMAXPY          592329 1.0 6.0866e+00 1.3 2.19e+10 1.1 0.0e+00 0.0e+00 0.0e+00  1  4  0  0  0   1  4  0  0  0 873511<br></div><div>MatSOR            790717 1.0 1.2933e+02 1.2 1.93e+11 1.1 0.0e+00 0.0e+00 0.0e+00 24 40  0  0  0  24 40  0  0  0 362525</div><div><div><br></div></div><div>For the functions requires communication, the time ratio is about (1.4-1.6)</div><div>VecDot            789772 1.0 8.4804e+01 1.4 1.46e+10 1.1 0.0e+00 0.0e+00 7.9e+05 14  3  0  0 40  14  3  0  0 40 41794<br></div><div><div>VecNorm           597914 1.0 7.6259e+01 1.6 1.10e+10 1.1 0.0e+00 0.0e+00 6.0e+05 12  2  0  0 30  12  2  0  0 30 34996</div></div><div><br></div><div>The full logsummary for this new run is here: <a href="https://googledrive.com/host/0BxEfb1tasJxhVkZ2NHJkSmF4LUU" target="_blank">https://googledrive.com/host/0BxEfb1tasJxhVkZ2NHJkSmF4LUU</a></div><div><br></div><div>Can we say now the load imbalance is from the network communication, instead of memory bandwidth?</div></div></div></div></blockquote><div><br></div><div>Actually now it looks even more like what Jed was saying. The 4 cores have much more available bandwidth.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks.</div><div><br></div><div>Xiangdong</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
</span>You can and should improve load balance before stressing about network<br>
costs.  This could be that the nodes aren't clean (running at different<br>
speeds) or that the partition is not balancing data.<br>
</blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>