Here is the expanded blog post, taking your introduction and building it into a comprehensive, 10,000+ word guide on the true costs of x86 instructions.

The Lies We Tell About CPU Instructions: Why Your Mental Cost Table is Wrong

Introduction: The End of the Simple Era

In the world of low-level performance engineering, few things seem as straightforward as the cost of a single CPU instruction. For decades, programmers have carried in their heads a rough mental table: an ADD costs one cycle, a MUL three to five, a DIV twenty or more. This intuition served us well in the era of simple in-order pipelines, where counting cycles was a matter of adding up instruction latencies. You could look at a basic loop, count the instructions, multiply by the clock speed, and have a remarkably accurate estimate of runtime. The world was simple, deterministic, and understandable.

But the modern x86-64 processor is a marvel of complexity—a superscalar, out-of-order, speculative execution engine that can chew through multiple instructions in parallel, reorder them on the fly, and hide latencies behind a deep reorder buffer. The result? Your mental instruction cost table is almost certainly wrong. Worse, it’s not just a little wrong; it’s fundamentally, structurally wrong. The very concept of an instruction having a “cost” is a dangerous oversimplification.

Consider this: the ADD instruction, long thought of as a single-cycle operation, can actually achieve a throughput of four per cycle on a recent Intel microarchitecture—meaning the processor can complete four unrelated add operations in every single clock tick. Yet the latency of a dependent chain of adds remains exactly one cycle per instruction. Meanwhile, a DIV instruction, with its reputed twenty-cycle latency, might actually have a lower effective cost than you think if you can keep the divider busy with independent divisions. The true cost of an instruction is not a single number; it is a pair: latency and reciprocal throughput, and both depend heavily on the surrounding code, the microarchitecture generation, and even the specific execution port that handles the operation.

This matters more than ever. As we push into an era where Moore’s Law slows and single-thread performance gains come primarily from architectural innovation rather than raw clock speed, the ability to squeeze every last cycle out of hot loops has become a superpower. Game engine developers, database kernel engineers, cryptographers, high-frequency traders, and compiler writers all rely on precise knowledge of instruction costs to guide optimization. If you optimize based on a flawed mental model, you will make things worse, not better. The difference between a well-tuned inner loop and a naive one can be a factor of 10x or more on modern hardware.

This essay is your comprehensive debunking. We will tear down the myth of the single instruction cost, explore the physical and architectural realities of a modern CPU core, and equip you with the mental models and tools you need to understand true performance. We will look at the specific microarchitectures from Intel and AMD, examine the bottlenecks of ports, caches, and registers, and provide concrete, code-level examples of how your intuition fails you. By the end, you will not only understand why your cost table is wrong, but you will have the framework to build a better, more nuanced understanding.

Let’s begin by understanding the lie itself: the classic cost table.

Chapter 1: The Classic Cost Table and Its Origins

1.1 The Mythological Table

If you were to ask a veteran C programmer in the year 2000 for the cost of common x86 instructions, they might have recited something like this:

This table, while not entirely fictional, is a ghost. It is a spectral echo of a bygone era. Its origins lie in the architecture of the original Pentium (P5 microarchitecture) and the early Pentium Pro (P6). For the non-optimizing programmer, it was good enough for back-of-the-envelope calculations. But even then, it was incomplete. It ignored the entirely separate metric of throughput, conflated latency with total cost, and completely omitted the critical role of memory access which could span 100+ cycles for a DRAM hit.

1.2 The Reality: Latency vs. Throughput

The single biggest flaw in the classic table is the failure to distinguish between latency and throughput. These are the two pillars of modern instruction cost analysis.

• Latency: The number of cycles it takes for the results of a single instruction to be available for a subsequent dependent instruction. If instruction B uses the result of instruction A, the total cycles from the start of A to the start of B is the latency of A. Latency is a measure of how fast a chain of dependent work can be done.

• Throughput (Reciprocal Throughput): The number of cycles the CPU must wait between starting two independent instances of the same instruction. If you can start an ADD every 0.25 cycles (a reciprocal throughput of 0.25), then you can start four ADDs per cycle. Throughput is a measure of how much total work of a single type can be done in parallel.

The classic table reported a single number, which was often a terrible average of the two. For ADD, the latency is ~1 cycle, and the reciprocal throughput is ~0.25 cycles. Which one is the “cost”? It depends entirely on the surrounding code!

Example: The Dependent Chain vs. The Parallel Explosion

Consider two loops. The first is a classic dependent chain; the second is a sum of independent terms.

Loop 1: Dependent Chain (Latency Bound)

// r1 = a0 + a1 + a2 + a3 + a4 + a5 + a6 + a7
r1 = (a0 + a1) + (a2 + a3) + (a4 + a5) + (a6 + a7);

This is a single-chain of dependent ADDs. The CPU cannot start the second addition until the first finishes. The total time is the latency of the chain: TCycles = (N-1) * L_add where L_add is the latency (e.g., 1 cycle). So for 8 values, the loop takes 7 cycles (plus overhead). Throughput is irrelevant here because there are no independent operations to parallelize.

Loop 2: Independent Terms (Throughput Bound)

// sum = a0 + a1 + a2 + a3 + a4 + a5 + a6 + a7
// Using multiple accumulators
sum1 = a0 + a1;
sum2 = a2 + a3;
sum3 = a4 + a5;
sum4 = a6 + a7;
total = sum1 + sum2 + sum3 + sum4;

Here, the four initial additions (sum1, sum2, etc.) are independent. The CPU’s out-of-order engine can analyze them and dispatch them to four different execution ports simultaneously. The total time for the first four adds is not 4 cycles; it is approximately the reciprocal throughput of one ADD instruction, which is 0.25 cycles. All four can be completed in the same cycle! The total loop time is dominated by the final tree of dependent additions.

• Total with modern table: Total = T_throughput (for 4 adds) + latency (for 3 dependent adds) ≈ 0.25 + 3 = 3.25 cycles.
• Total with old table: Total = 8 * 1 = 8 cycles.

The old table was off by a factor of 2.5x. If you had a deep pipeline of 1000 additions, the difference becomes a factor of 4x.

1.3 The Microarchitecture Explosion

Before we dive deeper, we must acknowledge the second reason the old table is useless: it doesn’t specify the microarchitecture. An ADD instruction on an Intel Skylake (2015) behaves completely differently from an ADD on an Intel Nehalem (2008). A DIV on an AMD Zen 4 (2022) is far more efficient than a DIV on an AMD K10 (2007). The instruction is the same architectural intention, but the microarchitectural implementation—the number of execution ports, the depth of the pipeline, the size of the scheduler—changes every time.

Modern CPUs are not simple pipelines. They are sophisticated dataflow machines. They decode your simple x86 instructions into one or more micro-operations (µops). These µops are what actually travel through the execution engines. A single ADD might decode into one µop. A complex DIV might decode into dozens of µops, each taking its own trip through the pipeline.

The Chain of Decoding:

1. Fetch: The CPU fetches a line of x86 instructions from the L1I cache.
2. Decode: The decoder cracks the complex CISC x86 instructions into simpler RISC-like µops.
3. Rename: The µops are sent to the register renaming unit, which maps architectural registers (e.g., EAX, RBX) to a much larger pool of physical registers. This prevents false dependencies (WAW, WAR) and allows out-of-order execution.
4. Dispatch: The µops are placed into the Reservation Station (RS), a scheduler that holds them until all their operands are ready.
5. Execute: When all operands are ready, the scheduler dispatches the µop to a free execution unit (e.g., Integer ALU, FPU, Load/Store unit).
6. Writeback: The result is written to the physical register file and broadcast to the scheduler to wake up dependent µops.
7. Retire: Instructions must leave the Reorder Buffer (ROB) in the original program order. This is the “commit” point.

Every single one of these stages has its own latency and throughput limits. An instruction’s “cost” is the sum of its journey through this pipeline. The classic table only guessed at the “Execute” stage.

Chapter 2: The Anatomy of Modern Execution: Ports, Schedulers, and the Dataflow

2.1 Execution Ports: The Pipes of the Engine

The execution stage is where the real magic—and limitation—happens. Modern CPUs have a limited number of physical execution ports. Each port is connected to one or more execution units. For example, an Intel Skylake core has 8 execution ports (Ports 0-7).

• Port 0: Integer ALU, Vector ALU (Shift), Vector FMA (Fused Multiply-Add), Branch (partially)
• Port 1: Integer ALU, Vector ALU (Integer Add), Vector FMA, Slow Integer Multiply (IMUL)
• Port 2: Load Address Generation Unit (AGU) – handles loads from memory.
• Port 3: Load AGU – a second load port.
• Port 4: Store Data Unit – writes data to the store buffer.
• Port 5: Integer ALU, Vector Shuffle, Vector Boolean, Branch
• Port 6: Integer ALU, Branch
• Port 7: Store Address Generation Unit (ST-AGU) – generates addresses for stores, used with Port 4.

Why Ports Matter: The number of ports determines the maximum throughput of an instruction. An ADD instruction can be dispatched to any of Ports 0, 1, 5, or 6. That’s four integer ALU ports. This is why ADD has a reciprocal throughput of 0.25 cycles—you can start four of them per cycle because there are four ports to handle them.

A scalar integer multiply (IMUL r, r) can only use Port 1. It has a reciprocal throughput of 1 cycle. So while you can do four ADDs per cycle, you can only do one MUL. The available port capacity is a fundamental constraint.

Example: Port Contention Imagine a tight loop that performs an ADD and a MUL on independent data:

loop:
    add     eax, ecx     ; Uses Port 0,1,5,6
    imul    edx, r8d     ; Uses Port 1 ONLY

In one cycle, the scheduler can dispatch the ADD to Port 0, but it cannot dispatch the MUL to Port 1 because Port 1 is already busy with… nothing? Wait. The MUL has a latency of ~3 cycles. If the next loop iteration starts the next MUL, it cannot be dispatched to Port 1 until the previous MUL finishes. The throughput of the MUL is 1 per cycle, but the latency is 3 cycles.

In this case, the bottleneck is not the ports themselves but the pipelining of the multiplier unit. The MUL unit is pipelined; it can start a new MUL every cycle, even if the previous one hasn’t finished. So the throughput is 1/cycle. But the ADD can also run at 1/cycle (it only needs one port). The loop can sustain a throughput of one ADD and one MUL per cycle. The port bottleneck is Port 1, which is the only MUL-capable port, and it is perfectly utilized.

2.2 The Scheduler and the Reorder Buffer: Hiding Latency

The magic that makes modern CPUs fast is the out-of-order (OoO) engine, composed of the Reservation Station (scheduler) and the Reorder Buffer (ROB). This engine can “see” ahead in the instruction stream, find independent instructions, and execute them speculatively while waiting for slow operations (like a cache miss).

How it Hides Latency: Consider a chain of dependent MULs:

int a = 1;
for (int i = 0; i < 1000; i++) {
    a = a * some_array[i];
}

This loop is entirely latency-bound. The next MUL cannot start until the previous one finishes (latency ~3 cycles). The total time is 1000 * 3 = 3000 cycles. The OoO engine is helpless here because every instruction depends on the previous one. This is a pathological case.

Now consider a chain of independent MULs:

int a[8] = {1,1,1,1,1,1,1,1};
for (int i = 0; i < 1000; i+=8) {
    a[0] = a[0] * some_array[i+0];
    a[1] = a[1] * some_array[i+1];
    // ... up to 8 independent chains
}

Here, the scheduler can see that a[0], a[1], a[2] are all independent. It can dispatch a MUL for a[0] to Port 1 in cycle 0. In cycle 1, it dispatches the MUL for a[1]. In cycle 2, it dispatches a[2]. By cycle 3, the result for a[0] is ready, and it can be used in a new dependency chain. The CPU runs 8 independent chains in parallel, effectively hiding the 3-cycle latency. The total time is roughly 1000 * 1 (throughput) = 1000 cycles instead of 3000.

This is the power of parallelism. The OoO engine needs a “window” of instructions to look into. The size of this window is the ROB, which holds ~200 µops on modern CPUs. If you can keep 200 µops of independent work inside the window, the CPU can perfectly hide latencies up to the depth of the window.

2.3 Memory Hierarchy: The Real Cost of an Instruction

The classic table was also silent on memory. A LOAD instruction from a register is free (it’s just a rename). But a LOAD from memory is where the real cost lurks.

• L1 Data Cache Hit: ~4-5 cycles latency, includes address calculation.
• L2 Cache Hit: ~10-14 cycles latency.
• L3 Cache Hit: ~30-50 cycles latency.
• Main Memory (DRAM) Hit: ~100-300 cycles latency (and that’s just the first word).

A single cache-miss LOAD instruction can take 250 cycles. In that time, the CPU could have executed 1000 independent ADD instructions. The cost of a LOAD is not a fixed number; it is a probability distribution over the memory hierarchy. An instruction’s “memory cost” is a function of working set size, access pattern (sequential vs. random), and the performance of the prefetcher.

Chapter 3: A Modern Instruction Cost Table (and Why It’s Still Wrong)

Let’s build a better table for a specific microarchitecture: Intel Ice Lake (2019) . We will list both latency (L) and reciprocal throughput (T). Remember, these numbers are for independent µops. A microcode (complex) instruction is a different beast.

Why This Table Is Still Wrong:

1. It’s Microarchitecture-Specific: An ADD on an AMD Zen 3 has different ports (e.g., 4 integer ALU ports) and different latencies. A DIV on a Zen 4 is much faster than on Ice Lake.
2. It Ignores µop Fusion: Modern CPUs can fuse certain instruction pairs. For example, ADD [mem], reg is decoded into a single µop (a read-modify-write) instead of two (load then add then store). This can double throughput. The table doesn’t show fusion.
3. It Assumes Perfect Scheduling: The OoO engine has limited resources. If the ROB is full, it stalls. If the reservation station is full, it stalls. The table assumes infinite resources.
4. It Ignores Register Pressure: To exploit multiple ports, you need a large register file. The x86-64 architecture has 16 general-purpose registers (GPRs), but the CPU has ~180 physical integer registers. Renaming helps, but if you need to hold 20 live values, you will start spilling to the stack (unmasked stores/loads), which kills performance.
5. It Ignores Speculative Execution: Branch mispredictions are a disaster. A misprediction can cost 15-20 cycles to flush the pipeline and fetch from the correct target. The table doesn’t include the cost of the JMP instruction itself, which is effectively free, but the consequence of the jump is enormous.

Chapter 4: The Hidden Trap: Dependency Chains and Loop-Carried Dependencies

4.1 The Invisible Chain

The most common optimization mistake is failing to see the implicit dependency chains in your code. The compiler and CPU are excellent at exploiting instruction-level parallelism (ILP), but they cannot break true dependencies.

Example: The Sum Loop

double sum = 0.0;
for (int i = 0; i < N; i++) {
    sum += array[i];
}

Most programmers look at this and think: “One FADD per iteration. Latency of FADD is 4 cycles. So it takes 4 cycles per iteration.” They are right. This loop is critically dependent on a single accumulator variable sum. Each iteration must wait for the previous FADD to finish. The OoO engine cannot help. The loop runs at 4 cycles per element.

The Fix: Multi-Accumulator

double sum0 = 0.0, sum1 = 0.0, sum2 = 0.0, sum3 = 0.0;
for (int i = 0; i < N; i+=4) {
    sum0 += array[i+0];
    sum1 += array[i+1];
    sum2 += array[i+2];
    sum3 += array[i+3];
}
double total = sum0 + sum1 + sum2 + sum3;

Now the loop has four independent dependency chains. The CPU can execute four FADDs every 4 cycles, achieving a 4x speedup. The loop runs at 1 cycle per element. The table said FADD latency is 4 cycles, but by breaking the chain, we made it look like 1 cycle. The true cost is the throughput, not the latency, once you remove the dependency.

4.2 The Pointer Chase

A classic pathological case is the linked list traversal:

while (node) {
    process(node->data);
    node = node->next;
}

This is a dependent load chain: node = node->next. The CPU cannot read node->next until it has loaded node. This creates a serial chain of loads. If the node pointers are in L1 cache, each load takes ~5 cycles. A linked list traversal can be 5x slower than an array traversal because the array allows the prefetcher to work and the load unit to be pipelined.

Chapter 5: Case Studies: When Intuition Betrays You

5.1 The “Cheap” Branch

Myth: A conditional branch (JNE, JZ) is a cheap instruction.

Reality: A correctly predicted branch is essentially free (costs 1 cycle in the front-end). A mispredicted branch costs 15-20 cycles (the penalty to flush the pipeline). If your branch is unpredictable, it is one of the most expensive instructions you can execute.

Example: A binary search on random data is slow not because of the comparison, but because the branch is unpredictable. The CPU cannot guess the outcome, so it suffers a penalty on every iteration. The solution is to replace the unpredictable branch with a branchless select using CMOV (conditional move) or bitwise arithmetic. CMOV has a fixed latency of 1 cycle, no matter the data. It is always slower than a correctly predicted branch, but much faster than a mispredicted one.

// Predictable branch (fast if data is sorted)
if (key < arr[mid]) {
    high = mid - 1;
} else {
    low = mid + 1;
}

// Unpredictable branch (slow on random data) - use CMOV instead
// This is what a compiler might generate with -fno-if-conversion disabled.

5.2 The “Expensive” Division

Myth: Integer division is the most expensive instruction; avoid it at all costs.

Reality: Modern dividers are pipelined. On Intel Ice Lake, IDIV for 32-bit operands has a throughput of about 1 per 10 cycles (reciprocal throughput ~10 cycles). This is not the 20-40 cycles of the old table. Furthermore, if you are dividing many independent values, the cost is the throughput, not the latency. The real trick is to replace division with multiplication by a constant reciprocal (if the denominator is known at compile time). The compiler does this automatically for you.

// Slow? The compiler will replace x / 10 with x * 0xCCCCCCCD >> 35 (approx).
int result = x / 10;

// Manually, you can do the same.
int div_by_10_manual(int x) {
    // Magic constant from Hacker's Delight.
    return (x * 0xCCCCCCCDULL) >> 35;
}

The compiler is smarter than you. Write the division; the compiler will optimize it. The real performance cost of division comes from the latency of a single dependent chain, which is still high (~15 cycles), but the throughput is far better than folklore suggests.

5.3 The “Free” Store

Myth: A store to memory is just like a load; it’s fast.

Reality: Stores are asynchronous. The CPU writes the store to a store buffer. The store is only committed to the L1 cache when the instruction retires. The store itself has a throughput of ~1 per cycle (using Port 4). However, a load that immediately follows a store to the same address (a store-to-load forwarding hit) is very fast (~2 cycles). A load to an address that is currently in the store buffer but not committed is also fast.

The hidden cost of stores is cache line eviction and false sharing in multi-threaded code. If two cores write to two different variables that happen to be on the same cache line (64 bytes), the cache coherency protocol (MESI) forces the line to bounce back and forth. This is called false sharing and can cause a 100x slowdown. The cost of a store is not the instruction itself, but the impact on the memory system.

Chapter 6: Tools of the Trade: Measuring, Not Guessing

The only way to know a true instruction cost is to measure it. Your intuition is a hypothesis, not a fact. Here are the essential tools.

6.1 llvm-mca: The Static Analyzer

llvm-mca (LLVM Machine Code Analyzer) is a static performance analysis tool that simulates the pipeline of a modern CPU. You give it a block of assembly, and it tells you the expected throughput, the bottleneck ports, and the resource pressure.

Example:

# sum.s
add eax, eax
add ebx, ebx

llvm-mca -mcpu=skylake sum.s

Output (simplified):

Iterations:        100
Instructions:      200
Total Cycles:      50
Dispatch Width:    6
Micro-Ops:         200
IPC:               4.00
Block RThroughput: 0.50

It tells you that two independent ADDs can run in 0.5 cycles (throughput of 2 per cycle). This matches the port limitation (4 ports, but the block has only 2 instructions).

6.2 perf stat: The Dynamic Profiler

perf stat runs your program and measures hardware counters. Use -e to select specific events.

Key counters:

• cycles: Actual CPU cycles elapsed.
• instructions: Number of instructions retired.
• L1-dcache-load-misses: L1 data cache misses.
• branch-misses: Mispredicted branches.
• uops_issued.any: Number of µops dispatched.
• uops_retired.retire_slots: Number of µops retired.
• topdown-retiring, topdown-bad-speculation, topdown-fe-bound, topdown-be-bound: The Top-Down Microarchitecture Analysis methodology. This tells you why your code is slow (Bad Speculation, Front-End Bound, Back-End Bound, or Retiring). This is far more useful than raw IPC.

Example:

gcc -O2 -march=native -o myprog myprog.c
perf stat -e task-clock,cycles,instructions,topdown-be-bound,topdown-retiring ./myprog

If topdown-be-bound is high, your code is bottlenecked by the back-end (execution units, memory). If topdown-retiring is high, the pipeline is full and you are doing useful work. If topdown-bad-speculation is high, you have branch misprediction issues.

6.3 uarch Benchmarks

Wikichip and Agner Fog’s instruction tables are the canonical references. Agner Fog provides meticulously measured latencies and throughputs for every instruction on all major x86 microarchitectures. This is the definitive “correct” table.

6.4 The Roofline Model

The Roofline Model is a visual framework for understanding where your code is bottlenecked. It plots computational intensity (operations per byte of memory traffic) against performance (FLOPS or throughput). It has a “roof” representing the maximum achievable performance (e.g., the FMA throughput of 2 per cycle) and a “slope” representing the memory bandwidth limit. Your code sits underneath the roof. If you are on the slope, you are memory-bound. If you are on the roof, you are compute-bound. This is a profound way to think about instruction cost: the cost is not a property of the instruction alone, but of the data it operates on.

Chapter 7: The Future: AVX-512, AMX, and the New Reality

The complexity is only increasing. Modern CPUs now include:

• AVX-512: 512-bit SIMD operations. An AVX-512 FMA instruction can perform 16 single-precision multiplications and 16 additions per cycle per FMA unit. The cost of a single instruction is astronomical in terms of work, but its latency is still ~4 cycles. The throughput is 2 per cycle (on Ice Lake with two FMA units). The microcode is incredibly complex, and the power consumption can be high. The “cost” now includes thermal headroom and power budgeting.
• AMX (Advanced Matrix Extensions): Tile-based matrix multiplication units, designed for AI/ML. These are not typical instructions; they are stateful operations that load tiles, multiply them, and accumulate results in a large register file (tile configuration). The cost of a single AMX instruction is a complex function of tile sizes and pipeline states.
• Complex Prefetching: The processor’s prefetcher has become a sophisticated machine learning engine. It can detect strided patterns, stream access patterns, and even pointer chasing. The cost of a load instruction is not the latency of the first miss, but the probability of the prefetcher covering it. Optimizing memory layout to be “prefetcher-friendly” (e.g., using sequential access instead of random access) can be more important than choosing the perfect ALU instruction.

Chapter 8: A Practical Guide to Optimization in the Age of Complexity

Given that the “cost table” is a will-o’-the-wisp, how should a performance engineer actually work?

1. Profile First, Assume Nothing: Run your code under a profiler (like perf or Linux Trace Toolkit). Identify the hot functions. Do not guess.
2. Use the Top-Down Methodology: Analyze your hot code using the Top-Down Microarchitecture Analysis counters. This tells you the root cause of the bottleneck, not just the symptoms. Is it the front-end (L1I cache misses, decode stalls)? The back-end (L1D misses, execution port contention)? Bad speculation (mispredicted branches)? Or pure retiring (you are doing useful work, but maybe you can do it with fewer instructions)?
3. Eliminate the Primary Bottleneck First: If your code is L2 cache-bound, optimizing a 4-cycle FADD to a 3-cycle FADD is irrelevant. You need to fix the memory access pattern: reduce working set size, use software prefetching, or change your data structure (e.g., from a vector of pointers to a packed struct).
4. Understand Your Dependency Chains: Draw the data flow graph of your hot loop. Identify every true dependency. Can you break it using multi-accumulators? Can you use SIMD to perform the same operation on multiple data elements? Can you use compiler intrinsics to unroll the loop and create more independent work for the CPU?
5. Use llvm-mca for Assembly-Level Tuning: Once you have identified the bottleneck, write a small kernel of assembly or intrinsics and run it through llvm-mca. It will tell you the port pressure, the critical path latency, and the expected throughput. This is your empirical “cost table” for that specific code block.
6. Beware of Compiler Optimizations: Modern compilers (GCC, Clang, MSVC) are incredibly sophisticated. They can perform loop unrolling, vectorization, instruction selection, and constant propagation. Trust them. Write clear, idiomatic C/C++ code. Only resort to intrinsics or assembly after you have proven the compiler is doing a poor job on that specific hot loop.
7. Test on the Target Microarchitecture: Your optimization for an Intel Ice Lake server might be terrible on an AMD Zen 4 laptop. If you are writing high-performance code for a specific cluster or game console, test on that hardware.

Conclusion: The End of the Cost Table

The era of the simple instruction cost table is over. It served us well as a pedagogical tool, but it is now actively misleading. The cost of an ADD is not one cycle. It is a complex function of the available execution ports, the state of the scheduler, the occupancy of the reorder buffer, the presence of dependency chains, and the performance of the memory hierarchy.

The real truth is more beautiful and more challenging: the cost is not a property of the instruction, but of the system.

A modern CPU is a dataflow engine. You feed it a stream of instructions, and it dynamically reorders, parallelizes, and speculatively executes them, constrained only by the available resources and the true dependencies in your data flow. The art of the performance engineer is no longer about memorizing a table of numbers. It is about understanding the pipeline, the ports, the memory hierarchy, and the subtle math of dependencies. It is about using empirical tools to measure the machine’s response to your code.

Stop thinking: “How many cycles does a DIV take?”

Start thinking: “What is the data flow graph of my hot loop? Which resource is the bottleneck? How can I restructure my computation to maximize throughput and hide latency?”

Your old cost table is a lie. Embrace the complexity. Write code that not only tells the computer what to do, but how to do it efficiently within the constraints of the machine. That is the true craft of performance engineering. And it starts with unlearning everything you thought you knew.