GPU computing
Some work is one long chain of decisions where each step depends on the last - a CPU is built for that. Other work is the same simple operation applied to millions of independent items at once: add these two million numbers, shade these two million pixels, multiply these huge matrices. GPU computing is using the graphics processor - a chip originally built to push pixels - as a general-purpose engine for that second kind of work, the massively parallel kind.
The key difference is the shape of the hardware. A CPU has a handful of big, clever cores tuned to finish one instruction stream as fast as possible, with deep out-of-order execution and large caches to hide every stall. A GPU instead has thousands of small, simple lanes grouped into many cores, all running together; it is a throughput-oriented device. It does not try to make a single thread fast - it tries to keep a huge number of threads in flight so that while some wait on memory, others compute, and the chip stays busy. The trade is stark: a GPU is brilliant when you have thousands of independent, similar tasks and terrible when the work is one branchy, dependent sequence. This is the heart of heterogeneous computing - using CPU and GPU together, each for what it is good at.
It matters because it is how modern machine learning, scientific simulation, graphics, and a growing share of data processing get their speed; a problem that maps well to the GPU can run an order of magnitude or more faster than on the CPU. But be candid about the cost. You must restructure the problem to be data-parallel, move data across a slow link between CPU and GPU memory (often the real bottleneck), and accept that divergent branches and irregular memory access can collapse the speedup. A GPU is not 'a faster CPU' - it is a different machine that rewards a different style of code.
// add two arrays of N elements: // CPU: for (i = 0; i < N; i++) c[i] = a[i] + b[i]; // one core walks all N in sequence // GPU: launch N threads; thread i computes c[i] = a[i] + b[i] // all i at once, in parallel
The same elementwise add, two ways: the CPU iterates; the GPU launches one thread per element and runs them together.
A GPU is not just a faster CPU. It wins only on data-parallel work, and moving data between CPU and GPU memory is frequently the real bottleneck - a kernel that runs in microseconds is worthless if you spend milliseconds copying its inputs across the bus. Branchy, dependent, or irregular code often runs slower on a GPU than on a CPU.