rdtsc in the Age of Sandybridge

Years ago I wrote a program that would dynamically measure the speed of my CPU. It would record the current number of CPU clock ticks with __rdtsc() (the C/C++ intrinsic for the rdtsc instruction), then wait some period of time (measured with QueryPerformanceCounter()), and then see how many CPU ticks had elapsed during that period. It was fascinating, in a pointless and geeky way, to see how the CPU clock speed changed as the load changed.

rdtsc has changed a lot since then. My Sandybridge CPU is rated at 2.20 GHz and the rdtsc instruction on it returns a rock-solid 2.195 GHz at all times. I could feel ripped off that my 2.20 GHz CPU runs 1.1% slow, but it turns out that isn’t the full story.

By using CPU-Z or Intel’s overnamed “Intel(R) Turbo Boost Technology Monitor 2.0” I can see that when my CPU is idle it drops to very low speeds, and when it is under heavy load it actually spikes up to around 3.0 GHz (2.993 GHz according to CPU-Z, which is probably more trustworthy than Intel’s potentially biased CPU speed monitor).

The actual peak CPU speed depends on the overall load of the CPU and GPU, which means that if you optimize your code really well then you might push the CPU so hard that it can’t overclock itself quite as much. That sentence just about makes my head explode.

On the code that I care about I find that my Sandybridge CPU usually runs at it’s peak speed of about 3.0 GHz. I can’t get it to thermally limit itself, even when pegging all four hyperthreaded cores.

What this means is that if I use __rdtsc() to measure how many clock cycles it takes to execute a function I am actually measuring how many ‘standardized’ clock cycles it takes to execute that function. The actual number of ‘real’ clock cycles is likely to be 3.0 / 2.2 GHz higher, or about 36%. My inner loop in a program I work on occasionally takes about 3.0 cycles to execute as measured by __rdtsc(), but that is actually 4.09 ‘real’ CPU cycles.

Here’s the test code if you want to try this on your computer:

// Use Query Performance Counter to get a nice accurate time-stamp.
__int64 GetQPCTime()
{
    LARGE_INTEGER qpcTime;
    QueryPerformanceCounter(&qpcTime);
    return qpcTime.QuadPart;
}

// Use QueryPerformanceCounter to interpret the results of GetQPCTime()
__int64 GetQPCRate()
{
    LARGE_INTEGER qpcRate;
    QueryPerformanceFrequency(&qpcRate);
    return qpcRate.QuadPart;
}

int _tmain(int argc, _TCHAR* argv[])
{
    const DWORD msDuration = 1000;
    const int iterations = 6;
    const double qpcRate = (double)GetQPCRate();

    // Measure the CPU speed reported by __rdtsc() when the
    // machine is mostly idle — CPU-Z shows the CPU is running slow.
    printf(“Idle CPU speed.\n”);
    for (int i = 0; i < iterations; ++i)
    {
        __int64 rdtscStart = __rdtsc();
        __int64 qpcStart = GetQPCTime();
        Sleep(msDuration);
        __int64 rdtscElapsed = __rdtsc() – rdtscStart;
        __int64 qpcElapsed = GetQPCTime() – qpcStart;
        printf(”    Clock speed = %1.3f GHz\n”, 1e-9 *
                rdtscElapsed / (qpcElapsed / qpcRate));
    }

    // Measure the CPU speed reported by __rdtsc() when the
    // machine is busy — CPU-Z shows the CPU is running fast.
    printf(“Busy CPU speed.\n”);
    for (int i = 0; i < iterations; ++i)
    {
        __int64 rdtscStart = __rdtsc();
        __int64 qpcStart = GetQPCTime();
        DWORD startTick = GetTickCount();
        for (;;)
        {
            DWORD tickDuration = GetTickCount() – startTick;
            if (tickDuration >= msDuration)
                break;
        }
        __int64 rdtscElapsed = __rdtsc() – rdtscStart;
        __int64 qpcElapsed = GetQPCTime() – qpcStart;
        printf(”    Clock speed = %1.3f GHz\n”, 1e-9 *
                rdtscElapsed / (qpcElapsed / qpcRate));
    }

    return 0;
}

The output of this program is so consistent that it is boring. The rdtsc instruction ticks along at the advertised speed, regardless of whether the CPU is running faster or slower than that speed.

Idle CPU speed.
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
Busy CPU speed.
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz
    Clock speed = 2.195 GHz

When running the first loop (the idle loop) the Intel monitoring tool shows:

and when running the second loop (the busy loop) it shows:

When running the first loop (the idle loop) CPU-Z shows:

and when running the second loop (the busy loop) it shows:

If you need a consistent timer that works across cores and can be used to measure time then this is good news. If you want to measure actual CPU clock cycles then you are out of luck. If you want consistency across a wide range of CPU families then it sucks to be you.

Update: section 16.11 of the Intel System Programming Guide documents this behavior of the Time-Stamp Counter. Roughly speaking it says that on older processors the clock rate changes, but on newer processors it remains uniform. It finishes by saying, of Constant TSC, “This is the architectural behavior moving forward.”

Wikipedia mentions how to check for Constant TSC on Linux.