RISC, CISC, GPUs and Parallel Systems

A RISC design typically emphasises a relatively regular set of simpler instructions, often with load/store access to memory and substantial use of registers. Regular instruction formats can simplify decoding and pipelining. A CISC design typically offers more complex instructions and addressing options, sometimes allowing one instruction to express work that would require several simpler instructions.

These are architectural tendencies rather than universal guarantees. A complex instruction need not finish in one clock cycle, and a RISC program need not always use less memory. Modern processors can decode complex instructions into simpler internal operations and combine features from several design traditions. Explain the mechanism relevant to the question rather than declaring one category always faster.

A GPU provides many processing resources suited to high-throughput operations across large amounts of data. Rendering can apply similar transformations to many vertices or pixels. Non-graphics examples include matrix calculations in scientific simulation or machine learning, where many related numerical operations can be scheduled together.

The classroom SIMD idea is that a common operation is applied across multiple data elements. Actual GPU execution models have further detail, so it is sufficient here to connect repeated similar work with parallel throughput. Irregular control flow, small workloads and frequent CPU-to-GPU transfers can reduce the benefit. A GPU is not automatically the best choice for a short sequence of dependent decisions.

A multicore CPU can run different threads or processes on different cores, subject to scheduling and program design. A parallel system can also use several processors or networked machines. Tasks must have work that can use those resources; one inherently sequential dependency chain cannot simply be divided into independent pieces.

Communication, synchronisation, load imbalance and the serial part of a program limit speedup. In an ideal example where half of the original running time remains serial and half is perfectly divided over four cores, time becomes 0.5+0.5/4=0.625 of the original: a speedup of 1.6. Real overhead can reduce this further. This model supports the reasoning; memorising a particular formula is not the purpose.

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.