What Is a CPU (and Why More Cores Isn't Always Faster)?

Quick answer
A CPU is the chip that executes instructions. It fetches an instruction, decodes it, does the arithmetic or logic, and writes the result back — billions of times a second.
A core is an independent execution unit. A thread is a second instruction stream sharing one core’s hardware, so 16 threads is not 16 cores.
Clock speed (GHz) says how many cycles per second, not how much work per cycle. A 3 GHz chip can beat a 4 GHz one by doing more per cycle.
Cache is tiny, very fast memory inside the chip that hides the ~100 nanosecond wait for RAM. It is why identical code runs at different speeds on different chips.
x86 (Intel, AMD) and ARM (Apple Silicon, phones, AWS Graviton) are different instruction sets — a binary built for one does not run on the other without translation.

What is a CPU, in one paragraph?

The CPU (central processing unit) is the part of a computer that executes instructions. A program — whether it was written in Python, Go, or Rust — is eventually turned into a long list of very small operations: add these two numbers, compare these two values, copy this value out of memory, jump to that instruction if the result was zero. The CPU reads them one after another and performs them. Everything else in the machine exists to feed it data and store the results.

Inside, a modern CPU is several parts working together: a control unit that decides what to do next, an arithmetic and logic unit (ALU) that does the maths, a small set of registers that hold the values being worked on right now, and cache to keep frequently used data close by. On a phone or a modern laptop, the CPU cores, memory controller, graphics, and often the network interfaces all sit on one piece of silicon called a system on a chip (SoC).

What actually makes a CPU fast?

Four things, and clock speed is only one of them. Clock speed is how many cycles per second the chip runs, measured in gigahertz — 3 GHz is three billion cycles per second. But what matters is instructions per cycle, usually called IPC: how much work the design extracts from each cycle. A newer architecture at 3 GHz with better IPC comfortably beats an older one at 4 GHz, which is why comparing two chips by gigahertz alone tells you almost nothing.

The other two are core count and how well the workload uses memory. Modern designs also run cores at different speeds: laptop and phone chips pair a few fast cores with several efficient ones, and boost clocks are sustained only briefly because of heat and power limits. A chip’s thermal design power (TDP) is the heat budget it is designed for, and it is why the same processor is much faster in a desktop with good cooling than in a thin laptop that has to throttle down under sustained load. A server chip is built to hold a lower clock indefinitely instead of a high one for ten seconds.

Cores, threads, and what ‘vCPU’ means

A physical core is a complete execution unit that can run one instruction stream. Simultaneous multithreading — Intel calls it Hyper-Threading — lets one core present two logical threads, usually gaining somewhere between 10% and 40% extra throughput rather than doubling anything. So a machine advertised as ‘8 cores, 16 threads’ has eight real cores, each juggling two streams. When a cloud provider sells you 2 vCPU, you are usually buying two of those logical slices of a shared physical core, which is why two vCPUs on a busy host can be much slower than two cores on your laptop.

More cores only help if the work can be split up. Rendering frames, serving many HTTP requests, and multiplying matrices all parallelise well. A single script that reads a file, transforms it, and writes it out does not: it is limited by the speed of one core, so a 32-core machine finishes no sooner than a 4-core one. This is the single most common sizing mistake — buying wider instead of faster for a workload that only ever uses one lane.

# What is actually in the machine you are running on
lscpu | grep -E 'Model name|Socket|Core|Thread|MHz'

# A single-core benchmark, if you want to compare two machines honestly
sysbench cpu --threads=1 run

Why cache is the part nobody mentions

A CPU cycle is measured in fractions of a nanosecond. Reading from main memory (RAM) takes roughly 100 nanoseconds — a few hundred cycles of doing nothing. To hide that gap, chips carry their own small, fast memory in three levels: L1 and L2 are private to a core and hold a few kilobytes to a few megabytes, and L3 is larger and shared between cores, typically tens of megabytes. If the data you need is in cache, the CPU keeps going; if it is not, it stalls.

This is the reason two programs that do the same amount of arithmetic can differ enormously in speed, and why data layout matters in hot code: walking an array in order is fast because the hardware prefetches it, while jumping around randomly in a large one is slow because nearly every access misses. It is also the honest explanation for why indexing a database makes queries faster and why a query that touches a million rows is slower than one that touches fifty: it is not about the CPU doing arithmetic, it is about avoiding trips to memory and disk.

x86 vs ARM, and why you keep meeting it

An instruction set is the vocabulary a CPU understands. Intel and AMD chips speak x86-64; Apple Silicon, most phones, and AWS Graviton servers speak ARM (specifically AArch64). The instruction sets are incompatible: a program compiled for x86 contains instructions an ARM chip cannot decode. Anything that runs the other architecture needs either a native build or a translation layer, which costs performance.

You will meet this in practice as multi-architecture container images. When you build an image on an Apple Silicon laptop and deploy it to an x86 server, the image must contain the right architecture or the container will refuse to start — the fix is to build for both with a buildx-style multi-platform build. Reading the ARM guide explains when choosing an ARM server is a genuine cost saving and when it is a compatibility trap.

Where this bites vibecoders
AI assistants write code for an abstract machine that has infinite fast CPU. The tell is code that does per-item work in a loop where a single database query would do, or that spawns a thread per task on a two-core VPS. Nothing in the code looks wrong, because the model has no idea whether the target is a 96-core server or a $5 instance sharing half a core with a noisy neighbour. Knowing your core count, whether your work is CPU-bound or waiting on I/O, and whether one core is fast changes what you ask the assistant for — and lets you tell a real performance fix from a cosmetic one.

Where AI coding assistants get this wrong

Sizing a workload by core count when the code only ever uses one core.
Assuming a vCPU is a dedicated physical core of your own.
Comparing processors by gigahertz instead of architecture and IPC.
Ignoring that laptop chips throttle under sustained load, so benchmarks lie about long jobs.
Deploying an image built for one architecture to a machine of another.
Treating CPU as the bottleneck when the code is actually waiting on RAM, disk, or the network.

Checklist

Know your core count, thread count, and whether one core is fast or many are slow.
Work out whether the task is CPU-bound or waiting on I/O before optimising anything.
Check whether the work parallelises at all before buying more cores.
Benchmark one thread, not just the whole machine.
Match the container image architecture to the host.
On a shared instance, expect noisy-neighbour variance and measure it.

FAQ

Is a higher GHz CPU always faster?

No. Clock speed only says how many cycles per second the chip completes. A newer design can do more work per cycle, so a 3 GHz chip often beats an older 4 GHz one. Core count, cache size, memory speed, and how long the chip can hold its boost clock all matter too.

How many cores do I need for a web app?

Fewer than you think. A typical app serving moderate traffic is limited by database queries, not CPU, and runs comfortably on two cores. Cores matter when you do real computation — video encoding, image processing, model training, or running many worker processes — and only if that work can actually be split up.

What is the difference between a core and a thread?

A core is a physical execution unit. A thread is an instruction stream that the operating system schedules. With simultaneous multithreading, one core runs two threads and gains some extra throughput — typically 10% to 40%, not 100% — because the two streams share the same arithmetic units and cache.