Everyone has used good old
time(NULL) to get timings accurate to the second. Some of you may have used
GetSystemTime() to get sub-second timings. The really clever have found
QueryPerformanceCounter, which give timings accurate to a millisecond or better (for the record, I'm not among the really clever - I found out about those two by reading the Python documentation... Thanks, Guido!).
But if you really want accurate timings, this code will give you timings accurate to the machine cycle, which on a 1 ghz machine is one nanosecond. On a 2 ghz machine, it's 1/2 nanosecond. Old 100 mhz machines will only get 10-nanosecond timings. You get the idea.
It requires a tiny bit of assembler, but it's worth it:
_asm lea ebx,cycles;
_asm mov [ebx],eax;
_asm mov [ebx+4],edx;
This code will work on Win9X or NT/2K and probably XP. Actually, it would even work in Linux if you can figure out how to get GCC to emit inline assembler!
Of course, the time comes out in cycles, not seconds, and oddly there seems to be no API to get the machine's speed. You can either "calibrate" the results (by getting the count, sleeping for (say) one second, getting the count again, and doing some trivial math), or just use cycles directly and don't worry about seconds (it's great for comparing one algorithm to another, or finding the slow parts of your program)
One warning, however: certain machines, notably laptops, can slow down their processor speed when nothing important seems to be happening. Since the calibration sleep is exactly one of those times, you can get some seriously wrong results from the calibration.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.