I am profiling Direct3D9 API calls. I have read a lot of documentation here that describes the process. I have a question though about calculating the elapsed clock cycles. Here is my current method:
// measurement vars
LARGE_INTEGER start, stop, freq;
//
// flush command buffer here
//
//
// issue begin query here
//
// start timer
QueryPerformanceCounter(&start);
//
//draw
//
//
// issue end query here and wait on results
//
// stop timer
QueryPerformanceCounter(&stop);
// calc elapsed ticks
stop.QuadPart -= start.QuadPart;
// get frequency
QueryPerformanceFrequency(&freq);
// ticks for easier handling
ULONG ticks = stop.QuadPart;
// calc elapsed clock cycles
cycles = (2.8E9 * ticks) / (double)freq.QuadPart;
My question concerns the value 2.8E9 which is supposed to represent the speed of the processor. Is this the correct way of calculating clock cycles? I am profiling single API calls and my results differ from those found on the above link. If I set the processor speed to 1E9 then the numbers are within range...I just wanted to check my method...
The number of processor cycles is (approximately) the difference.
LONGLONG cycles = stop.QuadPart - start.QuadPart;
The correct way to convert to SECONDS is:
double seconds = (double)cycles / (double)freq.QuadPart;
QueryPerformanceCounter used to be implemented as a wrapper around RDTSC but this doesn't work well with modern clock frequency stepping power-management. Therefore, QPC is now usually some other stable clock on the system so it might not necessarily be ' CPU processor cycles'.
If you actually want true 'CPU processor cycles' then you should use __rdtsc() intrinsic directly, but remember you don't have a robust way to convert it directly to time--and that on old AMD Athalon 64 machines you have problems of it not being sync'd between cores.
Reserve the use of ticksfor calls to GetTickCCount64 (or the deprecated GetTickCCount) which returns "ticks in milliseconds".