How a computer runs your code
A high-level but honest mental model of the CPU, memory, and the loop that drives everything.
- Describe the fetch–decode–execute loop in plain language
- Explain what memory is and how variables relate to it
- Distinguish compiling, interpreting, and just-in-time compilation
You don't need an electrical engineering degree to be a good programmer, but a rough, correct mental model of what happens when your code runs will save you countless hours. Let's open the box just far enough to be useful.
The machine is a fast, literal loop
At its heart a CPU does one boring thing, billions of times a second:
- Fetch the next instruction.
- Decode what it means.
- Execute it (add two numbers, compare two values, jump elsewhere).
- Repeat.
That's the whole show. Everything you've ever run — a game, a browser, an AI model — is this loop, executed unimaginably fast over very simple instructions. The "magic" is entirely in the arrangement of those simple steps.
Memory: addressable boxes
While it runs, your program needs somewhere to keep data. Memory (RAM) is an
enormous row of numbered boxes, each holding a value. A variable is really just a
human-friendly name for the address of a box. When you write count = 5,
the machine stores 5 in some box and remembers that count points there.
Two regions matter early on:
- The stack — fast, orderly scratch space for the local variables of the function currently running. It grows and shrinks as functions call and return.
- The heap — a larger, flexible area for data that needs to outlive a single function or whose size isn't known up front.
You'll rarely manage this by hand in modern languages, but knowing the words
demystifies a lot of error messages (stack overflow, out of memory).
From your text to those instructions
The CPU executes numeric machine instructions, not your source text. Languages bridge that gap in one of three ways:
- Compiled (Rust, Go, C): a compiler translates the whole program ahead of time into machine instructions. Fast to run; you ship a binary.
- Interpreted (the classic Python model): an interpreter reads and executes your program step by step, as it runs. Flexible; slower per step.
- Just-in-time (JIT) (JavaScript engines, modern Python builds): starts by interpreting, then compiles the hot, frequently-run parts to machine code while running. A blend of both.
The practical upshot: "slow code" is usually slow because of what it asks the machine to do (the algorithm), not which language ran it. We'll make that precise later in algorithms and complexity.
Where to go next
You now know what runs your instructions and where data lives while it does. Next we look at the data itself — data and types — and why the machine cares so much about what kind of value sits in each box.