Software is said to exhibit scalable parallelism if it can make use of additional processors to solve larger problems, i.e. this term refers to software for which Gustafson's law holds. Consider a program whose execution time is dominated by one or more loops, each of that updates every element of an array --- for example, the following finite difference heat equation stencil calculation:
for t := 0 to T do
for i := 1 to N-1 do
new(i) := (A(i-1) + A(i) + A(i) + A(i+1)) * .25
// explicit forward-difference with R = 0.25
end
for i := 1 to N-1 do
A(i) := new(i)
end
end
In the above code, we can execute all iterations of each "i" loop concurrently, i.e., turn each into a parallel loop. In such cases, it is often possible to make effective use of twice as many processors for a problem of array size 2N as for a problem of array size N. As in this example, scalable parallelism is typically a form of data parallelism. This form of parallelism is often the target of automatic parallelization of loops.
Distributed computing systems and non-uniform memory access architectures are typically the most easily scaled to large numbers of processors, and thus would seem a natural target for software that exhibits scalable parallelism. However, applications with scalable parallelism may not have parallelism of sufficiently coarse grain to run effectively on such systems (unless the software is embarrassingly parallel). In our example above, the second "i" loop is embarrassingly parallel, but in the first loop each iteration requires results produced in several prior iterations. Thus, for the first loop, parallelization may involve extensive communication or synchronization among processors, and thus only result in a net speedup if such interactions have very low overhead, or if the code can be transformed to resolve this issue (i.e., by combined scalable locality/scalable parallelism optimization[1]).