When optimizing low-level C or C++ code, conventional wisdom says that removing dead branches, redundant variables, and unused debug statements will make your code faster—or at least have zero impact. Yet, developers occasionally stumble upon a bewildering paradox: commenting out an inactive printf statement makes the program significantly slower.

In a benchmark testing whether natural numbers can be expressed as the sum of two squares, developers noticed that keeping a debug print guarded by if (n < 100) made the overall loop across millions of iterations up to 30% faster on Intel ICX and a few percent faster on MSVC. Even though the print never executed for $n \ge 100$, removing it degraded performance. Let's explore why this happens and how CPU architecture causes this counterintuitive behavior.

The Suspect Code

Consider the core checking routine for whether $n = a^2 + b^2$:

bool sum_2squares(unsigned int n) {
    unsigned int a2, b2, delta_a, delta_b, sum, limit = (unsigned int) sqrt(n);
    a2 = 0;
    delta_a = 1;
    b2 = limit * limit;
    delta_b = 2 * limit - 1;
    while (a2 <= n / 2) {
        sum = a2 + b2;
        if (sum == n) {
            // Commenting out this line causes an unexpected slowdown:
            // if (n < 100) printf("%u = %3u + %3u\n", n, a2, b2);
            return true;
        }
        a2 += delta_a;
        delta_a += 2;
        if (sum > n) {
            delta_a -= 2;
            a2 -= delta_a;
            b2 -= delta_b;
            delta_b = delta_b - 2;
        }
    }
    return n == sum;
}

When benchmarking across $10^7$ iterations, the condition n < 100 is only met 99 times. For the remaining 9,999,901 iterations, the CPU never executes the printf call. Yet without it, runtime on Intel compilers climbed from 7.8 seconds to 11.7 seconds.

Why Dead Code Changes Execution Speed

When high-level source code changes, compilers produce different machine code layout and register assignments. Even if the logic executed at runtime is identical, modern out-of-order x86 processors are extremely sensitive to microscopic layout differences.

1. Loop and Branch Target Alignment

Modern Intel and AMD processors read instructions in fixed-size blocks (typically 16, 32, or 64 bytes). Inside the CPU frontend, several structures handle these bytes:

  • Instruction Cache (L1i): Operates on 64-byte cache lines.
  • Instruction Fetch / Decode (MITE): Decodes instructions into micro-operations (uops), often restricted if instructions span across a 16-byte boundary.
  • Decoded Stream Buffer (DSB / uop Cache): Caches already-decoded uops in small sets.

When you insert or delete instructions anywhere in a function, the physical memory addresses of every subsequent instruction shift. If a critical loop label or branch target shifts from being aligned on a 16-byte or 32-byte boundary to sitting awkwardly across a boundary, the processor can suffer from frontend stalls, fetching fewer instructions per cycle.

2. Register Allocation and Calling Conventions

Introducing a call to an external function like printf completely changes how the compiler evaluates register usage across the function:

  • A function call invalidates caller-saved registers.
  • To keep variables alive across potential calls, the compiler must spill them to the stack or assign them to callee-saved registers (such as rbx, r12–r15 on x86-64).
  • In the assembly outputs from ICX, notice that the version with the debug print assigned ebx for arithmetic calculations, whereas the version without it assigned r10d. Different registers require different instruction prefixes (REX prefixes), which changes instruction length and affects uop decoding throughput.

3. Macro-Fusion and Branch Prediction

Compilers often emit adjacent pairs of instructions like cmp followed by jbe or je, which modern x86 cores fuse into a single internal micro-operation (Macro-Fusion). When surrounding code causes these instructions to cross particular boundaries (like a 32-byte or 64-byte boundary), macro-fusion can fail, increasing the number of uops that need execution ports.

How to Verify the Phenomenon

To confirm that instruction alignment or uop cache thrashing is the culprit, use hardware performance counters with tools like Linux perf or Intel VTune.

# Profile uop cache misses and frontend stalls
perf stat -e idq.dsb_cycles,idq.mite_cycles,frontend_retired.dsb_miss ./sum_squares_fast
perf stat -e idq.dsb_cycles,idq.mite_cycles,frontend_retired.dsb_miss ./sum_squares_slow

If the slow version shows significantly higher idq.mite_cycles (running out of the legacy decode pipeline) or elevated DSB misses, the performance drop is directly caused by code alignment shifting inside the frontend.

How to Fix Alignment Issues Consistently

You shouldn't rely on random debug prints to keep your code fast. Here is how to stabilize and maximize performance:

1. Force Code and Loop Alignment

Use compiler flags to force loops and functions to align on boundaries suitable for your target processor architecture:

  • GCC / Clang / Intel ICX: Add -falign-loops=32 -falign-functions=32.
  • MSVC: MSVC automatically aligns jump targets depending on optimization flags, but you can use #pragma loop(hint_parallel) or link-time optimization (/GL, /LTCG).

2. Profile-Guided Optimization (PGO)

PGO measures real branch frequencies during an instrumented run. It reorganizes code layout so that cold paths (like n < 100) are placed out-of-line into distant cold sections of the binary, ensuring hot loops stay tightly packed and aligned.

# Clang / ICX PGO workflow
icx -O3 -fprofile-generate main.cpp -o main_gen
./main_gen
icx -O3 -fprofile-use main.cpp -o main_opt

3. Improve the Core Algorithm

While fixing alignment recovers 20–30%, the underlying algorithm for the Sum of Two Squares problem can be improved dramatically. Rather than testing pairs up to $\sqrt{N}$ ($O(\sqrt{N})$ per number), natural numbers can be expressed as a sum of two squares if and only if their prime factorization contains no odd power of any prime of the form $4k + 3$ (Fermat's Theorem on sums of two squares). Using a linear sieve or trial factoring against precomputed primes will count valid numbers up to $10^9$ in seconds rather than hours.