What Is the Difference Between Weak and Strong Scaling?

Strong scaling measures how much faster a fixed-size problem finishes as you add processors. Weak scaling measures whether the run time stays constant when you add processors and grow the problem in proportion. Both terms come from high-performance computing (HPC), the field of running one large computation across many processors. A job that takes 10 hours on 1 processor and 1.7 hours on 8 processors shows strong scaling with a speedup of 5.9. A job that handles 1 million records per node in 60 minutes, and 8 million records on 8 nodes in 65 minutes, shows weak scaling. Its efficiency is 92 percent.

Strong scaling: fixed problem, more processors

In a strong scaling test, the total amount of work stays the same and only the processor count changes. The question is how much sooner the same answer arrives. The two measures are speedup and efficiency. T1 is the time on one processor and Tp is the time on p processors.

speedup(p)    = T1 / Tp
efficiency(p) = T1 / (p * Tp)

Perfect strong scaling gives a speedup equal to p and an efficiency of 100 percent. Real programs do worse because some part of the work cannot be divided. Reading the input file, setting up the problem, and combining the final result are done once, no matter how many processors wait for them.

Amdahl's law states the limit. Let f be the parallel fraction of the work. The best possible speedup on p processors is given below.

speedup(p) = 1 / ((1 - f) + f / p)

For a program that is 95 percent parallel, the speedup on 8 processors is 5.9 and the efficiency is 74 percent. On 64 processors the speedup is 15.4 and the efficiency is 24 percent. As p grows without bound, the speedup can never exceed 1 / (1 - f), which is 20 for this program. Beyond that point, added processors only add cost.

Weak scaling: problem grows with processors

In a weak scaling test, the work per processor stays fixed and the total problem grows in proportion to the processor count. The question is whether the run time stays flat. Efficiency is the only measure needed.

weak efficiency(p) = T1 / Tp

Here T1 is the time for one unit of work on one processor and Tp is the time for p units on p processors. Perfect weak scaling gives 100 percent, meaning the larger problem took no longer. The loss comes from communication: each processor must exchange boundary data with its neighbors, and that exchange grows with p.

Gustafson's law gives the matching view. Let s be the serial fraction of the run time on p processors. The scaled speedup is given below.

scaled speedup(p) = p - s * (p - 1)

With s equal to 0.05 and p equal to 64, the scaled speedup is 60.9. The serial part does not shrink the gain very much, because the problem grew alongside the processor count. This is why weak scaling results usually look better than strong scaling results for the same code.

Strong vs weak scaling

How to run a scaling study

A strong scaling study runs the same input at 1, 2, 4, 8, 16, and 32 processors. It plots speedup against p. The point where the curve flattens is the practical maximum for that input. A weak scaling study runs an input of size N on 1 processor, 2N on 2, 4N on 4, and so on. It plots time against p. A flat line is the goal. Supercomputing centers such as NERSC ask for both plots when a team requests time, because the two plots answer different budget questions.

Small inputs give misleading strong scaling results, because the serial fraction dominates. Choose the largest input that fits on one node for the strong test. For the weak test, choose a per-node size that fills that node's memory to about 70 to 80 percent.

What this means for system design

Web and data systems use the same two ideas under different names. Reducing the time of one batch job by adding workers is a strong scaling problem, and Amdahl's law applies. The limit is the serial part: the single coordinator, the final merge, or the one table that every worker writes to. A nightly report that spends 30 minutes in a serial load step will never finish in less than 30 minutes, however many workers are added.

Serving more users by adding servers is a weak scaling problem. The work per server stays fixed at, for example, 500 requests per second, and the fleet grows with traffic. The goal is a flat latency curve, which is the weak scaling efficiency of the service. The losses are the same as in HPC: shared state, cross-node communication, and any part that is not partitioned. Horizontal scaling succeeds when each server owns its share of the data and rarely exchanges data with the others.

Key Takeaways

• Strong scaling fixes the problem and adds processors. Measure speedup, expect Amdahl's limit of 1 / (1 - f).
• Weak scaling grows the problem with the processors. Measure whether time stays flat, expect losses from communication.
• A program that is 95 percent parallel can never exceed a 20 times speedup. Above about 32 processors, more than half of the added hardware is idle.
• Horizontal scaling of a web service is a weak scaling question. The serial parts, such as a single coordinator or a shared table, set the limit.

The scalability and partitioning chapters of Grokking System Design Fundamentals cover the design side of these limits.

Grokking the System Design Interview shows how to estimate capacity and find the serial part in a real design.

For parallel work inside one process, see Grokking Multithreading and Concurrency for Coding Interviews.