MIMD, SIMD and Parallel Speedup

MIMD means multiple instruction streams operating on multiple data streams. Multicore CPU resources can run different threads or tasks, for example one handling requests while another processes an independent calculation. Software, scheduling and data dependencies determine whether the available cores can perform useful work simultaneously. Several ready tasks on one core may be interleaved concurrently without executing at the same physical instant.

SIMD means a common instruction operation applied to multiple data elements. The syllabus uses this model to explain GPU-style data parallelism: many pixels, vertices or numerical values can undergo related operations. Actual GPU execution models include further scheduling and control-flow detail; a simple SIMD diagram is a useful abstraction rather than a complete description of every device.

Scroll the diagram to see the full view.

A large image filter can apply similar calculations across many pixels, offering substantial parallel work. A short decision chain in which each step depends on the previous result may offer little independent work. Irregular branches, unequal task sizes and limited memory bandwidth can leave processing resources waiting. A larger core count does not eliminate a program’s dependencies.

Moving data between host and accelerator, starting work and returning results can cost time. If a GPU calculation takes 2 ms but preparation/transfers take 8 ms, its total is 10 ms. Compare that with the complete CPU route, not just the 2 ms arithmetic kernel. Keeping reusable data near the processing resource can improve an appropriate workload, but capacity and access patterns still constrain it.

Suppose 30% of original execution time is inherently serial and 70% can be divided perfectly over four processors with no overhead. Normalised time becomes 0.30+0.70/4=0.475, giving speedup 1/0.475≈2.11. Four processors do not give four times the speed. Even infinitely many ideal processors cannot reduce the serial 0.30 part, giving a model limit of approximately 3.33.

Real communication, synchronisation and imbalance add further costs. Shared state may require coordination to prevent races, and measuring throughput is different from measuring one request’s latency. A useful recommendation identifies the independent units, their data movement, the serial section and the resource overhead. Support it with the question’s evidence rather than claiming a GPU is best simply because it has many processing resources.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.