How to get timings as fine-grained as one nanosecond or better

Introduction

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 QueryPerformanceFrequency and 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:

__int64 GetMachineCycleCount()
{      
   __int64 cycles;
   _asm rdtsc; // won't work on 486 or below - only pentium or above
   _asm lea ebx,cycles;
   _asm mov [ebx],eax;
   _asm mov [ebx+4],edx;
   return cycles;
}

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.