 |
Accurate Timing For Profiling
Submitted by |
When trying to get accurate frame rate or other timing info in order to profile
your code, the normal clock routines leave you hanging. Both
_ftime() and clock() have a resolution of several
milliseconds, so they aren't appropriate for timing very short routines or
getting accurate timings of frame rate (if you use them, your frame rate will
bounce around a lot). Here's a routine that gives you an exact cycle count for
your process, and some tools to interpret the output. Thanks to Aaron O. for
telling me about rdtsc.
#typedef ULONGLONG uint64;
uint64 getCycleCount()
{
uint32 timehi, timelo;
// Use the assembly instruction rdtsc, which gets the current
// cycle count (since the process started) and puts it in edx:eax.
__asm
{
rdtsc
mov timehi, edx;
mov timelo, eax;
}
return ((uint64)timehi << 32) + (uint64)timelo;
} |
To time a routine, call it twice and subtract the two counts:
uint64 time0 = getCycleCount();
// call your routine
myRoutine();
uint64 cycleCount = getCycleCount - time0; |
I usually like to see both the cycle count and the time in milliseconds.
Create a variable called processorSpeed and set it to the number
of cycles per second your machine gets (mine is 300MHz, so processorSpeed =
300000000). Here is some code to format the output nicely:
uint64 processorSpeedMilliseconds = processorSpeed / 1000;
// milliseconds, Megacycles
int ms, Mc;
// ms = (x cycles)(processorSpeed cycles/second) * (1000 ms/second)
// Mc = (x cycles) / (1e6)
ms = cycleCount / processorSpeedMilliseconds;
Mc = cycleCount / 1000000;
printf("Time: %d Megacycles/%d milliseconds", Mc, ms); |
Finally, your frame rate is 1000 / ms. Happy profiling!
Morgan http://graphics3d.com/matrix
Morgan Systems
|
The zip file viewer built into the Developer Toolbox made use
of the zlib library, as well as the zlibdll source additions.
|
