<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I have seen some people claim that strong-scaling is harder to achieve than weak scaling (e.g., <a href="https://www.sharcnet.ca/help/index.php/Measuring_Parallel_Scaling_Performance" target="_blank">https://www.sharcnet.ca<wbr>/help/index.php/Measuring_Para<wbr>llel_Scaling_Performance</a>) and generally speaking it makes sense - communication overhead increases with concurrency.</div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>I would back up and avoid this sort of competitive thing. Weak and strong scaling are different, but valid metrics. They each tell you different things.  Are oranges better than apples? Depends but they are both useful and of the same basic class.</div><div><br></div><div>Just to add, I've started to like Jed's metric of "dynamic range" (for lack of a better word). This is like strong scaling except instead of fixing the problem and increasing the parallelism you fix the parallelism and decrease the problem size. Then plot this with Time vs. N/Time (rate). This has the nice property, like weak scaling, a horizontal line is perfect. The rollover point is the lower bound on turnaround time (I call these turnaround time plots sometimes), and both axis are interesting (size, P or N, is not interesting, but rate and time are). But, this is just different.  Because it keeps parallelism the same, your latencies are a constant (ignoring algorithmic effects of problem size), so in a sense it is between strong and weak scaling.</div><div><br></div></div></div></div>