Read this as a study guide instead
Clock speed, cores versus threads.
These commands only read information — they change nothing. Run the block for your OS, then use the table to read your own numbers against the ideas above.
Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeedWhat you should see One row per processor: NumberOfCores is physical cores, NumberOfLogicalProcessors is hardware threads, MaxClockSpeed is the rated clock in MHz.
$env:NUMBER_OF_PROCESSORSWhat you should see A single number: how many hardware threads Windows can schedule. On a 4-core chip with SMT this reads 8.
sysctl -n machdep.cpu.brand_string
sysctl -n hw.physicalcpu
sysctl -n hw.logicalcpuWhat you should see Three lines: the chip's name, then physical cores, then hardware threads. Equal core and thread counts means no SMT — normal on Apple Silicon.
sysctl -n hw.cpufrequency
system_profiler SPHardwareDataTypeWhat you should see On Intel Macs the first command prints the clock rate in Hz; the second lists the chip, core counts, and memory.
Note On Apple Silicon hw.cpufrequency usually prints nothing at all. That absence is the lesson: there is no single clock number - performance and efficiency cores run at different, changing speeds, so Apple reports the chip name instead of a GHz figure.
lscpuWhat you should see A full summary. Multiply Core(s) per socket by Socket(s) for physical cores; CPU(s) is the thread count; the MHz lines show the clock range.
nproc
lscpu | grep -E 'Model name|^CPU\(s\)|Thread|Core|MHz'What you should see nproc prints the thread count on its own; the filtered lscpu shows only the model, count, and clock lines that matter here.
| Concept | Windows | macOS | Linux |
|---|---|---|---|
| Cores | NumberOfCores | hw.physicalcpu | Core(s) per socket x Socket(s) |
| Threads | NumberOfLogicalProcessors | hw.logicalcpu | CPU(s) |
| Clock speed | MaxClockSpeed (MHz) | hw.cpufrequency (Intel only) | CPU max MHz |
These are the exact fragments the model serves — also available as an ordered study guide.
A processor is not clever. It is fast, and it is relentless, but the thing it does is almost embarrassingly simple: it runs one tiny loop over and over, billions of times a second. Grab the next instruction, work out what it says, do it, then grab the next one. That loop is the whole job.
Each instruction is just a number sitting in memory — a bit pattern the chip knows how to act on, no more mysterious than any other number a computer stores. The processor reads them one after another and carries each one out. There is no hidden intelligence deciding what to do next; there is only the next instruction, and the loop that consumes it.
Everything people say about a CPU — how many gigahertz it runs at, how many cores and threads it has — is really a statement about that loop: how fast it turns, and how many copies of it run at once. Understanding the loop first makes the rest of the spec sheet stop being jargon.
One turn of the loop has three steps. First the processor fetches the next instruction — it reads it out of memory, where the program is waiting as a run of numbers. Then it decodes that instruction: a part of the chip called the control unit interprets the bit pattern and works out which operation it names and what it should act on. Finally it executes — the relevant part of the processor actually carries the operation out.
Then the loop repeats with the next instruction, and the next, and the next. This is the fetch-decode-execute cycle, and it runs like a cook working down a recipe one line at a time — read the next step, work out what it means, do it, then move to the next — one small, self-contained step at a time, in strict order, with the processor never running ahead of the instruction in front of it.
The operations themselves come from the chip's instruction set — the fixed vocabulary of things it knows how to do, which later concepts explore. What matters here is the shape: fetch, decode, execute, repeat. Every program you have ever run, however elaborate, was this loop turning fast enough to look like magic.
The loop does not turn whenever it feels like it. A steady signal called the clock ticks at a fixed rate, and each tick nudges the work forward by one step. The clock is the drumbeat of the whole chip — it like a metronome ticking a steady beat, setting how many steps happen each second without deciding what any step is, deciding how many steps happen per second without deciding what any of them do.
Clock speed is measured in gigahertz. One gigahertz (GHz) is one billion ticks per second, so a chip described as running at a few gigahertz is being paced a few billion times every second. Modern desktop and laptop processors run at roughly 2 to 5 GHz as of the mid-2020s — a range, not a single magic number, and one that has been remarkably stable for years.
A faster clock means more steps per second, which up to a point means more work done. But the clock only sets the tempo; it says nothing about whether the steps are useful, and a chip idling through billions of pointless ticks is no faster at the thing you care about.
The obvious way to make a processor faster is to raise the clock speed, and for decades that is exactly what happened — each generation ticked faster than the last. Then, in the mid-2000s, it mostly stopped. Clock speeds have climbed only slowly since, and the big gains started coming from other design changes instead.
The wall is heat. The faster a chip's clock runs, the more power it draws and the more heat it throws off, and the relationship is steep — pushing the clock higher costs far more power than the extra speed seems to promise. Past a point, the chip produces more heat than any reasonable cooler can carry away, and transistors do not survive being cooked. There is a ceiling, and by the mid-2000s mainstream chips had run into it.
So the industry changed the question. If one loop cannot safely turn much faster, the way forward is to run more loops at once — which is exactly what cores and threads are for.
A core is one complete instruction-cycle engine: one fetch-decode-execute loop, with everything it needs to run a program on its own. A multi-core processor puts two or more of these separate engines on a single chip, and they run instructions at the same time. Where a single core does one thing at a time, a four-core chip can genuinely be doing four things at once.
This is real parallelism, and it is the answer to the clock-speed wall: rather than making one loop turn faster, put more loops side by side. A chip with more cores can carry more work in the same instant, and this is why core counts kept climbing while clock speeds stalled.
The catch is that the work has to be splittable. Two cores finish a job in half the time only if the job can be cut into two pieces that run independently; a task that must happen in strict order gets no faster no matter how many cores sit idle beside it. More cores raise the ceiling on total work, not the speed of any single unbroken chain of steps.
A single core rarely runs flat out. It regularly stalls for a moment — waiting on a value it needs before it can take the next step — and during those gaps its machinery sits idle. Simultaneous multithreading, which Intel markets as Hyper-Threading, lets one physical core hold two separate instruction streams, called threads, and fill the idle gaps in one stream with ready work from the other.
To the operating system, a core with this feature looks like two, so a chip is often described with two numbers: a processor advertised as four cores and eight threads has four real cores, each presenting two threads. It works like the difference between several cooks working at once and one cook starting a second dish while the first is in the oven. The threads are not extra cores — they are a way to keep one core busier, squeezing useful work out of ticks that would otherwise be wasted.
That is the whole distinction. Cores are independent engines that add real parallel capacity; threads are a trick for using a single engine more fully. Both help, but they help differently, and a spec sheet that reports both is telling you two separate things about how much the chip can juggle.
Every CPU you might buy or rent is sold with the same three numbers, and they are exactly the three this concept covers. Clock speed in gigahertz is how fast one loop turns. Core count is how many independent loops run at once. Thread count is how many streams those cores can juggle. "Four cores, eight threads at 3.5 GHz" is no longer a wall of jargon — it is a description of the loop and how many of it you get.
Which number matters depends on the work. Sizing a machine to host a game server or a home lab, where many players or many services run at once, leans on cores and threads — more independent work in flight. A task that is one long unbroken chain of steps, like much of the control code on a small robot, leans instead on clock speed and on how much each tick accomplishes, because extra cores cannot break a sequential job apart.
So the spec sheet is a set of trade-offs, not a ranking. The fastest chip for one job is the wrong chip for another, and knowing whether your workload wants more loops or faster ones is the difference between paying for hardware you use and hardware you waste.