strong vs weak scaling
There are two honest questions you can ask of a parallel program, and they have different answers. The first: 'I have one fixed job — if I throw more workers at it, how much faster does it finish?' The second: 'If I want to do a bigger job in the same time, how many more workers do I need?' These are strong scaling and weak scaling, and confusing them is how people end up surprised that their code 'stops scaling' when it is in fact behaving exactly as the laws predict.
Strong scaling fixes the total problem size and increases the number of processors p. The metric is speed-up, S(p) = T(1) / T(p), ideally equal to p, and parallel efficiency, E(p) = S(p) / p, ideally 100 percent. Strong scaling is the hard regime: as you add processors, each one's share of work shrinks while the fixed costs (communication, synchronisation, the serial fraction) do not, so efficiency falls — eventually each processor is doing so little real work that overhead dominates. Amdahl's law is precisely the ceiling on strong scaling. Weak scaling, instead, grows the problem size in proportion to p, keeping the work per processor constant. The metric is whether the runtime stays roughly flat as you scale up both the problem and the machine together. Weak scaling is the kinder regime — Gustafson's observation that bigger machines are used for bigger problems lives here — and many real simulations weak-scale to enormous core counts even when they strong-scale poorly.
Which one matters depends on your goal. If you have a single fixed simulation that takes too long, you care about strong scaling, and you will hit a wall set by the serial fraction and communication. If you want higher resolution or a bigger domain and are willing to use a proportionally bigger machine, you care about weak scaling, which is usually far more forgiving. Reporting a speed-up number without saying which kind of scaling you measured is meaningless — a code can show a beautiful weak-scaling curve and a disappointing strong-scaling one on the very same machine, and both can be honest.
A weather model on a fixed 100-km grid is strong-scaled: 1 core takes 1000 s, 100 cores take 14 s (efficiency 71 percent), but 1000 cores take only 3 s (efficiency 33 percent) because communication now dominates. The same model weak-scaled — refine the grid as you add cores so each core always owns the same number of cells — holds the runtime near 14 s from 100 cores up to 100000, because each core's workload never changes.
Strong: fixed problem, more cores -> efficiency falls. Weak: problem grows with cores -> runtime flat.
An efficiency above 100 percent (superlinear speed-up) is real but usually a cache effect: split across more cores, each core's slice finally fits in cache, so per-core speed jumps. It is not a violation of any law — it just means your one-core baseline was hobbled by cache misses.