A debug print line seems to make code execution unexpectedly faster. Commenting out a printf that is conditional on n<200 slows things down when n is much larger.

How is the conditional print that never executes for n>200 speeding things up?

This toy code arises from a question on Math SE What is the most efficient way to determine if a natural number N can be written as the sum of two squares?. It is a surprisingly tough problem with a single thread unvectorised solution taking around 4 hours to count them out to 10^9.

That question gives a naïve algorithm which is easy to check and asks if there is a faster way. I thought that avoiding multiplies and sqrt in hte main loop would speed it up even if it remains O(sqrt(N)).

This is my first attempt. The odd thing was that my initial routine with a debug print in for small n was actually faster than any of my later attempts to simplify and optimise it once I had it working.

The least subtle and applying to both MSVC and Intel ICX compilers is that commenting out a debugging conditional printf slows things down! In the case of Intel ICX 2026.2.1 by almost 30% (MSVC by 2.5%).

I'm at a loss to explain this. Intel generated code is also notably faster than MSVC. I may be missing something obvious. Timings table - power of 10 increase in N roughly increases computation time by 32x.

I had expected that deleting the debugging test code which prints a solution for N<200 would speed things up. But the opposite was the case. I have repeated the timings several times because I didn't believe what I was seeing.

I also found that the fairly simple code for sum_2squares shown below is very hard to optimise further (but that is a story for another question). This is the test code - most interesting speed difference is on the Intel ICX 2025.2.1 compiler:

#include 
#include 
#include 

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) // solution
        {
//            if (n<100) printf("%u = %3u + %3u = %3u^2 + %u^2\n", n, a2, b2, (delta_a-1)/2, (delta_b+1)/2);  // commenting this debugging line slows it down!
            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;
}

int main()
{
    unsigned int count = 0;
    unsigned int limit = 10;
    time_t start, end;
    start = clock();
    printf("N\t count\t time/s\n");
    for (unsigned int i = 1; i <= 10000000; i++) // runtime about 20s (gets 30x slower
    {
        if (sum_2squares(i)) count++;
        if (i % limit == 0)
        {
            printf("%-9u %-9u  ", i, count);
            end = clock();
            printf("%6.3f\n", (float)(end - start) / CLOCKS_PER_SEC);

            limit *= 10;
        }
    }
}

I'm using Intel ICX 2025.2.1 with +O3 and all gofaster options. The timing behaviour is reproducible on Godbolt test range reduced for runtime <2s. Timings can be a bit erratic there. The speed difference is only about 10% on the latest 2026.0 version but still present.

I'm guessing the test and branch which is never taken somehow prevents a pipeline stall. But it is just a guess. I couldn't really spot an obvious cause. I'd like to understand better what is going on. Any other speed enhancements are welcome too.

I'm aware there are lots of sum of two squares questions on SO already and that the Hermite-Serrat algorithm might be the method of choice here but in this question I am concerned with the weird effect of a conditional print on the speed of a brute force attack.