Cores
In short: Standalone processing units within a CPU — a multi-core CPU can execute several instruction streams simultaneously instead of one after another.
In more detail: In the past, a CPU had exactly one core; today’s processors usually have 4 to 16+ cores. However, software has to be explicitly written for parallelism (multithreading) to actually benefit from multiple cores — a single, sequential task always only fully utilises one core.
In Depth
Why multi-core CPUs came about
Before the multi-core era, CPU performance was increased almost exclusively via the clock rate — more computing cycles per second directly meant more performance. In the mid-2000s, this approach hit physical limits: higher clock rates produce disproportionately more waste heat (power dissipation grows roughly with the square of voltage and linearly with frequency), which could no longer be sensibly dissipated with the cooling methods of the time. The manufacturers’ answer was to pack several, moderately clocked cores onto the same chip instead of a single, ever-faster-clocked core — more parallel work instead of more speed per step of work.
Amdahl’s law: the limits of parallelisation
The crucial catch: more cores only help if the running software can actually execute several threads at once (multithreading) — a classic, strictly sequential program (step 1 has to finish before step 2 can start) doesn’t benefit from additional cores at all, since it can only fully utilise one core anyway. This phenomenon is described by “Amdahl’s law”: the speedup gained from parallelisation is limited by the necessarily sequential portion of a task, no matter how many cores are available — if a task has, say, 10% strictly sequential portion, even with infinitely many cores, at most a 10x speedup is possible, never more.
Performance cores and efficiency cores
Newer CPU generations (e.g. Intel’s “hybrid” architecture since the 12th Core generation) combine different core types on the same chip: powerful “P-cores” (performance cores) for demanding, time-critical tasks and more economical “E-cores” (efficiency cores) for background tasks — similar to the principle originating from ARM-based smartphone chips (called “big.LITTLE” there). The operating system has to intelligently decide which task runs best on which core type.
Core count in practice
Some tasks are also fundamentally hard to parallelise (e.g. when each computation step necessarily builds on the result of the previous one), which is why single-core performance remains a central spec even with 16-core CPUs, especially for interactive applications like games, where often only a few cores are really heavily loaded. For highly parallelisable tasks like video encoding or compiling large software projects, a high core count, by contrast, pays off directly.
Cores vs. threads: the distinction
It’s important to distinguish between physical cores and logical threads: technologies like Hyper-Threading/SMT (Simultaneous Multithreading) let a single physical core manage two instruction streams at once, by better utilising unused execution units within the core — a 8-core CPU with SMT thereby appears to the operating system as 16 logical processors. However, the speedup from SMT is considerably smaller than a real additional physical core (often only 10-30% more throughput for parallelisable tasks), since both logical threads still share the same physical computing hardware.
How the operating system distributes tasks
Distributing individual programs and their threads across available cores is handled by the operating system’s “scheduler” — it continuously decides, within fractions of a second, which thread gets computing time on which core next, based on priority, waiting time, and (with hybrid architectures) which core type fits best. If a program isn’t explicitly programmed for multithreading, it stays bound to a single logical processor at all times, no matter how many other cores in the system sit unused — a common reason why some older software barely benefits from additional cores.
See also: CPU, Threads, Clock speed (GHz)