QueryPerformance counter in multicore systems with variable clock speeds

Question

QueryPerformanceFrequency() and QueryPerformanceCounter() functions are said to be the best according to the MSDN article Game Timing and Multicore Processors. But in case of no support for it, I can use timeGetTime() or just GetTickCount().

1. Is QueryPerformanceFrequency() the same as the CPU clock or is it using its own clock or something that has its own frequency which does not change over time?
2. What if the frequency changes over time randomly (especially in laptops)
3. How do I use the SetThreadAffinityMask function? (Some code I have seen uses the function to change it to "1" and then use the counter and change the mask again to old value. Why is that? Is it correct?)
4. Is it correct to use the QueryPerformanceFrequency() function only once and calculating delta time values by dividing with the frequency in case/question 1? Or is it fixed by case 2?

Answer 1

1. QPCs underlying implementation varies widely. In some cases it is, but usually it isn't.
2. That will effect RDTSC, but not QPC.
3. That is to prevent the thread from moving from one CPU core to another. It may help avoid high resolution timing methods reporting negative time passing (it happens...). Generally not recommended though.
4. The frequency of QPC is constant. At least on a given system, at least until reboot.

But you're not necessarily asking the right questions...

The four commonly used timing functions on windows are: GetTickCount, timeGetTime, QueryPerformanceCounter (QPC), and RDTSC

My recommendations among those:

Game logic timing should be done with timeGetTime. It is simple, reliable, and has sufficient resolution for that purpose. (edit: default resolution varies - you can call timeBeginPeriod to force it to 1 millisecond resolution though)

GetTickCount should not be used. It's resolution is too poor for either game logic or performance monitoring (64 Hertz - a nasty frequency as it creates a beat frequency with the typical monitor refresh rate). It is the fastest timing function call IIRC, but I can't find a scenario in which that makes up for its poor resolution. (edit: rumor has it that timeBeginPeriod can improve the resolution of GetTickCount - that rumor is FALSE)

RDTSC & QPC are both too unreliable / quirky for simple game logic timing, but better suited for performance measurements. RDTSC has issues that make it painful to use if you want units independent of CPU frequency changes, and you usually need asm to use it. QPC usually just works... but when it goes wrong it can go very wrong, and it goes wrong in a very wide variety of ways (sometimes it's really slow, sometimes it has frequent small negative deltas, sometimes it has infrequent large negative deltas (not wrap-arounds), sometimes it's just completely psychotic, etc). RDTSC is pretty much always faster, and usually significantly better resolution. Overall I prefer RDTSC for in-house use just because it is faster and thus produces fewer distortions in the times its measuring. On customers machines, it's a much closer call - QPC is easier to justify due to Microsoft pushing it, and it works without complications more often, but the wide variety of ways it can screw up on customer machines that you'll never see in-house is a major drawback in my view.

Answer 2

QPF/QPC are the best if you need a high-precision timer (the returned value is in nanoseconds, but that doesn't mean precision is 1 nanosec). Otherwise, just use GetTickCount() (in milliseconds). Both versions should properly handle variable CPU frequency (for example, on laptops with power saving options).

I have no idea how an affinity mask can help to retrieve the system time.

The proper way to get a high-precision time is to call both QPF and QPC and calculate time as:

double seconds = QPC / QPF;

EDIT:

GetTickCount() has poor precision, something like 5 milliseconds, but it is still suitable for most applications. For measuring really small time periods there's the single option: QPC/QPF.

Answer 3

I personally prefer the time stamp counter which is a 64-bit counter in the x86 architecture which increments for every internal clock cycle. It is read using the rdtsc instruction and returns the counter value in the edx:eax registers (x86-32) and rdx:rax (x86-64).

There have been issues with the instruction but that was many years ago. Today "green functionality" resulting in load-dependent execution frequency changes make calculating elapsed times more difficult but elapsed clock cycles aren't a problem.

unsigned long long startCycle, endCycle, elapsedCycles, overhead;

// @ start of program

overhead=instruction_rdtsc ();
overhead=instruction_rdtsc ()-overhead;

// preparing to measure

startCycle=instruction_rdtsc ();

// (sequence to measure)

endCycle=instruction_rdtsc ();

elapsedCycles=endCycle-startCycle-overhead;

The overhead of the instruction itself should be determined. I have found that the overhead on an intel processor is smaller than on AMD processors. The overhead should be measured several times - say in a loop - to find the lowest possible value. The longer sequences being measured the less of an issue the overhead becomes. The instruction makes it possible to insert permanent performance metering in an application to be able to measure its actual performance under normal (non-performance testing) execution.

Due to pipelining and out-of-order execution issues very short sequences should not be measured. Some suggest inserting the cpuid instruction before rdtsc but that only means that the actual clock count becomes greater than it actuall is. I see cycle counts of 30 or so as indicative whereas those around 100 or greater are generally reliable. In-between there is a gray zone.