iTranslated by AI
Prologue: Source Code as a "Request" — Blasphemy against the CPU
F1 Racers Know the Tire Composition
I almost fainted when I saw this question on a Q&A site.
Q. "Is there any point in studying how a CPU works?"
The best answer to this symbolized the pathology of modern engineering.
A. "Someone who wants to learn car driving techniques doesn't need to know the mixing ratio of tires. Software people don't need hardware knowledge."
It sounds plausible at first glance.
Many "engineers" nod at these words, feel relieved, and then stop thinking.
"Oh, I don't need to know the difficult stuff."
But let me be clear
If you are aiming to be a "Sunday driver" (driving for weekend shopping), then that is correct.
Step on the gas to move, step on the brake to stop.
It's fine if the inside of the hood is a black box.
But if you are aiming to be an F1 racer (a professional engineer), this becomes a fatal lie.
Professionals push the "limits"
F1 racers know the grip limits of their tires.
They can shave off tenths of a second precisely because they know the physics: at what road temperature the rubber starts to melt, and how many Gs they can withstand in a corner.
If there were a racer who said, "I don't need to know about tires," he would either crash into a wall at the first corner or be in last place because he's driving too safely.
Software Engineers: Look Under the Hood
Programming is exactly the same.
If you're building an internal tool that "just needs to work," you might not need hardware knowledge.
However,
- Why does this app drain the smartphone's battery?
- Why does the server crash when traffic spikes?
- Why is your code 100 times slower than your senior's?
All the answers lie under the hood (CPU, memory, bus).
Engineers who only know the steering of high-level languages will find themselves standing dazed when trouble occurs, staring blankly at the open hood.
Sweet Words Are a "Curse"
The sweet words telling you that "you don't need to know hardware" are a curse designed to keep you as just a consumer.
We are not consumers. We are creators.
That is why we open the hood, get covered in oil, and learn the structure.
"Python's Magic" vs "Rust's Discipline"
Now, before we look under the hood, let's take a look at the code you usually write.
Here is some simple code that just prints text to the screen.
Python:
print("Hello, World!")
Rust:
fn main() {
println!("Hello, World!");
}
The appearance is almost identical. Both output text to the screen.
But the physical cost is as different as night and day.
Behind Python (Extravagant Hospitality)
The moment you write print, a massive VM (Virtual Machine) kicks in behind the scenes.
- The interpreter translates line by line
- Variable types are dynamically inferred
- Memory is allocated for garbage collection
- Reference counts are managed
- Finally, a system call is issued
For just a single line of a "request," tens of thousands of CPU cycles are wasted.
This is like "a crowd of servants running around for the King (you)."
It's convenient, but incredibly heavy.
Behind Rust (Military Discipline)
On the other hand, Rust code is compiled (pre-translated).
The println! macro is expanded and eventually becomes machine code that the CPU can understand directly.
There is no unnecessary hospitality. Only the required instructions are executed coldly and efficiently.
But don't misunderstand
Using Rust doesn't automatically make things fast.
Rust is merely a corrective brace designed to make you follow physical discipline (memory ownership and lifetimes).
If you don't understand the meaning of that discipline, you can still produce slow code even when writing in Rust.
A language is not a magic wand. It is merely a tool for following the laws of physics.
A Stubborn Craftsman and an Inflexible Translator
Imagine the CPU as an extremely stubborn craftsman.
In his small, hot workshop (registers and ALU), he silently performs only the prescribed steps (machine language) at a terrifying speed.
It's useless to ask him to "do it more efficiently."
He only acts exactly as he is told.
And the compiler is an inflexible translator.
It translates the "human language (high-level language)" you wrote into "craftsman language (machine language)" that the craftsman can understand.
Cruel Reality: The Translator Doesn't Capture Your Intent
There is an important point here.
This translator will not capture your "intent."
Even if you wish for it to "run faster," the translator simply converts it into machine language.
Even if you wish for it to "save memory," the translator simply converts it into machine language.
The translator translates your code literally.
It doesn't care how inefficient or how many wasteful movements it forces upon the craftsman (CPU).
Reliance on Optimization Options (-O3)
At this point, you might be thinking:
"Then why not just leave it to the compiler? If I turn on the optimization option (
-O3), won't it just automatically generate fast code?"
Let me be blunt: that is complacency.
Compilers are certainly brilliant. However, compilers cannot beat the laws of physics.
- CPU registers (workbenches) are finite.
- Memory access (trips to the warehouse) is 100 times slower than register access.
- If a cache miss occurs, it becomes another 100 times slower.
- A context switch is a heavy task comparable to moving houses.
These are unalterable physical constraints.
No matter how hard a compiler tries, it cannot exceed the speed of light or ignore the heat generated by silicon.
Unconscious "Craftsman Abuse"
If you don't know these constraints, you will continue to write code that unconsciously "abuses the craftsman."
For example, what if a loop you wrote, thinking it was just a "small calculation," actually causes a massive amount of cache misses, exhausting the craftsman with marathon trips to and from the warehouse?
For example, what if the asynchronous processing you wrote, thinking it was "simple and readable," actually triggers frequent context switches, forcing the craftsman to move houses 1,000 times per second?
The compiler won't tell you that.
The craftsman (CPU) will silently perform the inefficient work without complaint, merely venting out Heat.
Why You Need to Know the "Low Level"
The answer is simple.
Because what you are fighting is not a bug. It is the "laws of physics."
Three Walls That Cannot Be Avoided
-
The Wall of Light Speed
Electrical signals cannot exceed the speed of light. This is why CPU clocks have plateaued at GHz levels. -
The Violence of Distance
Accessing memory (RAM) is as distant to the CPU as a "business trip to Brazil." A cache miss is like stopping your work to go pick up a package on the other side of the planet. -
The Curse of Thermodynamics
When a CPU calculates, it generates heat. When it generates heat, the clock speed drops. Heat never betrays you.
You Cannot Escape Physics
These cannot be avoided, regardless of the high-level language or framework you use.
Whether you use libraries or let AI write your code, the laws of physics are absolute.
However, you can understand them.
And, through design, you can turn them into your allies.
Only Those Who Know the "Chains" Gain True Freedom
This series exists to make you aware of the chains that bind you.
The Three Chains
-
The CPU is not "calculating." It is just a switch.
Transistors merely repeat the ON/OFF of voltage. "Thinking" does not exist. -
Memory is not an infinite canvas. It is a fragmented back alley.
The craftsman (CPU) desperately moves back and forth through a fragmented address space. -
Algorithms are not magic. They are an equivalent exchange of time and space.
O(n log n) is not a "formula," but an estimate of "physical workload."
The Fate of Those Who Do Not Know the Chains
Those who do not know these "chains" will forever dance inside an invisible cage called physics.
Lamenting:
"It's slow for some reason"
"It won't work for some reason"
"It crashes for some reason"
The Freedom of Those Who Know the Chains
But those who know the chains are different.
When you know the length, weight, and shape of the chains, you gain the maximum freedom within those constraints.
Instead of forcing the craftsman (CPU) beyond his limits, you give him the work he is best at. You reduce the trips to the warehouse (memory) and maximize the use of the workbench at hand (cache).
That is professional engineering.
Engineers Are Masters of Physics, Not Its Slaves
In this series, we will thoroughly learn the physical constraints of hardware.
But this is not about surrendering to physics.
It is to understand physics, utilize physics, and master physics.
- Once you understand that a context switch is "moving house," you can design to avoid unnecessary moves.
- Once you understand that memory access is a "round trip to the warehouse," you can write algorithms that maximize the use of the workbench at hand (cache).
At that point, for the first time, your code will stop being a "poem" and evolve into a blueprint for physical phenomena.
What This Series Will Cover
We will descend into the details where the silicon gods dwell.
Vol.1 Physics Edition: Knowing the "Pain" of Hardware
-
Prologue: "Requests" Named Source Code
F1 racers and Sunday drivers. Three walls, three chains. -
Chapter 1: The Giant's Thick Fingers (Data Types and Alignment)
Starting from the dream of a 1-bit CPU, through the reality of 64-bit, and into the physical gaps called padding. Foundations for quantum and the philosophies of Intel/Arm. -
Chapter 2: The Lonely Speed Demon and the Stopped Clock (Pipelining and Speculative Execution)
The CPU cannot wait for memory. So, it takes a "gamble." The madness of speculative execution. -
Chapter 3: The Violence of Distance (Memory Hierarchy and Caching)
L1 cache is the desk, RAM is Brazil. The meaningless business trips of pointer chasing. -
Chapter 4: The Eviction Siren (Context Switching)
The OS as a ruthless manager. The moving hell of "Time's up. Get out." -
Final Chapter: Why Your Code Is Slow
Submission to the laws of physics. A bridge to Vol. 2 (Thinking Edition).
Vol.2 Thinking Edition: Increasing the "Resolution" of Algorithms
-
Prologue: Algorithms are "Structures," Not Just "Procedures"
-
Chapter 1: Recursion and Loops (Techniques to confine the infinite within the finite)
The memory device called the stack. The miracle of Tail Call Optimization. -
Chapter 2: Data Structures (Building "Meaning" on the wasteland of memory)
Arrays and Linked Lists. The magic of Hash Tables. Why B-Trees are not binary trees. -
Chapter 3: Computational Complexity (Big O) (The battle against the lifespan of the universe)
O(n²) is unacceptable. The physics of the Database N+1 problem. -
Chapter 4: State Machines as Blueprints
Why flowcharts lie. A real-world example of payment flows. -
Chapter 5: Answers from Parallel Worlds (Quantum Algorithms)
Qubits, superposition, observation. A world that cannot be copied. Registers that break if you look at them. -
Chapter 2: The Key Named Prime Factorization (Shor's Algorithm)
The fictional quantum language Q++. Conversion to the period-finding problem. -
Chapter 7: Revealing Answers Through Wave Interference (Quantum Fourier Transform QFT)
Conditional rotation. The magic of computational complexity. Visualizing the rhythm of dividing 15. -
Final Chapter: The Staircase of Primes and Quantum Chaos (Connecting to the Riemann Hypothesis)
The Montgomery-Odlyzko conjecture. Is the universe calculating prime numbers?
Vol.3 Design Edition: The Battle to Protect "Order"
-
Prologue: Why Programs Rot as They Grow Massive
-
Chapter 1: Don't "Taxidermize" the Domain (OOP vs DOD)
Why Object-Oriented Programming lost to physics. The return to Data-Oriented Design. -
Chapter 2: The Prison Named the "Waiting Box" (Event-Driven and State Machines)
Don't put a "Wait" box in your flowchart. The world won't stop for you. -
Final Chapter: The Engineer as Maxwell's Demon
The battle against entropy. We are demons who turn chaos into order using electrical energy.
Now, Let's Peer into the Abyss
By the time you finish reading this series, you will never be able to write code the same way again.
- Every time you write a
forloop, you will begin to hear the sound of cache misses. - Every time you define a
class, memory fragmentation will become visible to you. - Every time you write
await, you will start to feel guilty about the CPU idle time.
And that's okay.
That is precisely what "awakening" as an engineer means.
You Are Standing at a Crossroads Now
There are two paths ahead.
Path A: Comfortable Ignorance
The path of deciding that "as long as it works, it's fine," and surrendering yourself to frameworks and libraries.
You will likely live peacefully as a Sunday driver.
Path B: The Painful Truth
The path of knowing the chains of physics and, while suffering under their weight, attaining the maximum freedom within those constraints.
You will push the limits as an F1 racer.
Which one do you choose?
If you choose Path B, turn the page.
We will talk about everything, from the smallest unit of 1-bit to the truth of the universe (entropy).
Next: Chapter 1: "The Giant's Thick Fingers (Data Types and Alignment)"
We start with the "ideal" of a 1-bit CPU and then confront the constraints of the "reality" that is the 64-bit CPU.
Discussion