Strong Scaling
Strong scaling fixes the problem size and adds processors, measuring how much faster a fixed workload runs as parallelism grows.
Fixed work, more workers
Strong scaling asks: for a problem of fixed total size, how does run time fall as processor count rises? Ideal strong scaling is linear speedup, doubling the processors halves the time. Speedup is defined as the one-processor time divided by the N-processor time; parallel efficiency is that speedup divided by N.
Why it saturates
Strong scaling is bounded by Amdahl's law. Any serial fraction of the code becomes an ever-larger share of the shrinking run time. Meanwhile the work per processor drops, so fixed per-step costs, communication latency, synchronization, and startup, come to dominate. Beyond some point, adding processors barely helps or even hurts.
A worked feel
If 95% of a code is parallel and 5% is serial, the best possible strong-scaling speedup is 20x, no matter how many processors are added. At 64 processors the actual speedup is already far below 64. This is why reducing the serial fraction matters more than adding hardware.
Communication-to-computation ratio
- More processors means smaller local subdomains
- Surface-to-volume ratio rises, so communication grows relative to compute
- At fine granularity, latency-bound halo exchanges dominate
Reading a strong-scaling plot
Plot speedup against processor count. The curve follows the ideal line at first, then bends away as overheads bite. The knee marks the practical limit for that problem size. To keep scaling past it, one usually grows the problem too, which is measured by weak scaling instead.