[petsc-users] strong-scaling vs weak-scaling

[Karl Rupp]

Hi Justin,

> I have seen some people claim that strong-scaling is harder to achieve
> than weak scaling
> (e.g., https://www.sharcnet.ca/help/index.php/Measuring_Parallel_Scaling_Performance)
> and generally speaking it makes sense - communication overhead increases
> with concurrency.
>
> However, we know that most PETSc solvers/applications are not only
> memory-bandwidth bound, but may not scale as well w.r.t. problem size as
> other solvers (e.g., ILU(0) may beat out GAMG for small elliptic
> problems but GAMG will eventually beat out ILU(0) for larger problems),
> so wouldn't weak-scaling not only be the more interesting but more
> difficult performance metric to achieve? Strong-scaling issues arise
> mostly from communication overhead but weak-scaling issues may come from
> that and also solver/algorithmic scalability w.r.t problem size (e.g.,
> problem size N takes 10*T seconds to compute but problem size 2*N takes
> 50*T seconds to compute).
>
> In other words, if one were to propose or design a new algorithm/solver
> capable of handling large-scale problems, would it be equally if not
> more important to show the weak-scaling potential? Because if you really
> think about it, a "truly efficient" algorithm will be less likely to
> scale in the strong sense but computation time will be close to linearly
> proportional to problem size (hence better scaling in the weak-sense).
> It seems if I am trying to convince someone that a proposed
> computational framework is "high performing" without getting too deep
> into performance modeling, a poor parallel efficiency (arising due to
> good sequential efficiency) in the strong sense may not look promising.

These are all valid thoughts. Let me add another perspective: If you are 
only interested in the machine aspects of scaling, you could run for a 
fixed number of solver iterations. That allows you to focus on the 
actual computational work done and your results will exclusively reflect 
the machine's performance. Thus, even though fixing solver iterations 
and thus not running solvers to convergence is a bad shortcut from the 
solver point of view, it can be a handy way of eliminating algorithmic 
fluctuations. (Clearly, this simplistic approach has not only been used, 
but also abused...)

Best regards,
Karli