Cloud & Infrastructure
Strong versus weak scaling with a worked benchmark
A practical guide to telling the two scaling tests apart, running them on a small example and reading the results before deciding whether to add more hardware.
01
Step one: fix what stays constant
Strong scaling holds the total problem size constant and increases processors. Weak scaling grows the problem in proportion to processors, so each one keeps the same workload. Choose based on your question. If you want an existing job to finish sooner, test strong scaling. If you want to solve larger problems in similar time, test weak scaling. Write down the input, software version, node type and number of repeats before starting. Run each configuration at least three times and use the median, because shared clusters can introduce noise that would otherwise distort the comparison.
02
Step two: run and calculate
Worked example: a simulation takes 800 seconds on 1 core, 410 on 2, 215 on 4 and 120 on 8. Speedup is the single-core time divided by each time: 1.95, 3.72 and 6.67. Efficiency is speedup divided by core count: 97 percent, 93 percent and 83 percent. For a weak test, you would double the grid with each doubling of cores and hope the time stays near 800 seconds. Record both tables in the same format so the team can compare them quickly and spot where behavior changes instead of relying on memory or screenshots.
03
Step three: decide what to do next
Read the efficiency column against a threshold your team agrees on in advance, such as 80 percent. In the example, eight cores still clear that bar, so more cores may help, but the downward trend suggests checking communication time and serial sections before buying capacity. If efficiency fell sharply at four cores, profile memory bandwidth and load balance first. Then change one factor, rerun the same table and keep the old results beside it. The decision is a documented comparison that shows whether a code change or additional hardware produced the improvement.