The Lie
The map you were given is incomplete.
You were taught that computers are mathematical machines. You were told that a + b is an
addition, that array[i] is a lookup, and that algorithms are abstract recipes for truth. You
were led to believe that Big-O notation describes the speed of code, and that complexity is a measure of
logic.
The map is useful, but it hides the cost.
A computer is not a math machine. It is a physics engine. It is a dense city of billions of microscopic switches, screaming with electricity, fighting against heat, capacitance, and the speed of light. At any moment, a computer is nothing more than its State: the contents of its memory, registers, and wires. Every line of code you write is a request to evolve this state over time.
When you write int a = 5; in C++ or Java, you imagine a clean integer sitting in a box.
In pathological cases, that simple assignment can trigger a page fault, stall a pipeline for 300
cycles, summon
the operating system kernel, and heat up the silicon enough to throttle the clock speed. The "5" is
irrelevant. The cost was the movement.
The simulators in this book do not model exact voltages or specific chip layouts. They model constraints, costs, and consequences. If a simulator feels slow, wasteful, or unfair—that is the point.
The Map is Not the Territory
The reason performance bugs feel "magical" to most developers—why a loop becomes 10x slower just because you iterated columns instead of rows—is because they are navigating with a map of "Logic" while walking through a terrain of "Physics."
If you treat memory as a flat tape (Logic), you will never understand why a Linked List is slower than an Array. If you treat branches as simple decisions, you will never understand why sorting an array makes processing it faster.
In this book, we are not going to destroy the map. We are going to annotate it with Physics.
Time is Currency
Nothing in a computer happens instantly. Every action consumes time. Time is the currency of computation. We pay for logic with nanoseconds.
- Distance: Moving data costs time (Latency).
- Uncertainty: Guessing wrong costs time (Branch Misprediction).
- Contention: Waiting for resources costs time (Queueing).
- Heat: Moving too fast destroys the hardware (Throttling).
We will not study how things work. We will study why they break.
Throughout this book, we will measure time, waste, and waiting—not to optimize prematurely, but to understand reality.
We will verify every truth by measuring it, and we will find that our software is constantly negotiating a peace treaty with the hardware underneath it.
Is Big-O Notation useless then?
Do I need to know Physics to write Python?
Why "Physics Engine"? Why not just "Architecture"?
Can't the Compiler fix all of this?
Welcome to the machine.