Electronics

CPU — Central Processing Unit

Every microcontroller in the Embedded domain has one of these at its center, just a much smaller, simpler version. This page is the general concept — the processor that actually executes instructions, one at a time, extremely fast, with no understanding of what any of them are "for."

Quick reference

What it is: The processor that fetches, decodes, and executes instructions — the component actually performing computation.
Mental model: An extremely fast, extremely literal reader following a recipe one step at a time — never skipping ahead, never improvising beyond exactly what the instruction says.
Key numbers: Clock speed in GHz (billions of cycles/second); core count; cache measured in KB (L1) to MB (L2/L3).
Reach for it when: Describing raw sequential/general-purpose compute capability — not massively parallel work, which is a GPU's job.

The fetch-decode-execute cycle

Every single instruction a CPU ever runs goes through the same basic loop:

This loop is the entire job — a CPU has no higher-level understanding of the program it's running, only this cycle, repeated relentlessly.

Clock speed — and why GHz alone doesn't tell the whole story

Clock speed, measured in GHz, is how many of those cycles the CPU completes per second — a 3 GHz CPU completes 3 billion cycles every second. But different CPU architectures accomplish different amounts of real work per cycle (IPC, instructions per cycle), which is exactly why a 3 GHz chip from one generation can outperform a 4 GHz chip from an older one — clock speed alone is only half the story.

Cores and threads

A single-core CPU runs one instruction stream at a time. A multi-core CPU has several genuinely independent execution units on one chip, capable of running that many separate instruction streams truly in parallel — the reason "how many cores" matters for anything that can actually be split into independent pieces of work. Software that can't be split this way sees no benefit from extra cores at all, no matter how many are available.

The cache hierarchy

Fetching data from main system memory takes far longer, in CPU-cycle terms, than the CPU itself runs — so every modern CPU keeps small, extremely fast copies of recently-used data close by:

L1 cache: Smallest and fastest, private to each core — tens of KB.
L2 cache: Larger, still fast, usually private per core or shared by a small cluster — hundreds of KB to a few MB.
L3 cache: Largest and slowest of the three, shared across all cores — several MB to tens of MB.

Missing all three levels and having to fetch from main RAM is dramatically slower than a cache hit — this hierarchy exists specifically to hide that gap as much as possible.

Real-world applications

Desktop, laptop, and server processors — the general-purpose case this page describes directly.
Phone/tablet SoCs — a mobile CPU is the same fetch-decode-execute concept, tuned hard for power efficiency over raw peak speed.
Microcontroller cores — see the Embedded domain — a microcontroller's own core is a tiny, often single-instruction-per-cycle, extremely power-conscious relative of everything on this page.

Gotchas

Field notes

Comparing two CPUs by clock speed alone, across different architectures or generations, is a common and genuinely misleading shortcut — real-world benchmarks account for IPC differences clock speed can't capture.
More cores doesn't help a workload that's fundamentally single-threaded — the classic "why isn't my 16-core machine faster at this one task" question almost always traces back to software that simply can't use the extra cores.
Sustained heavy load causes real heat, and a CPU will deliberately reduce its own clock speed to stay within safe operating temperature — see Cooling for why this is protective behavior, not a fault.