Is gettimeofday() guaranteed to be of microsecond resolution?

Maybe. But you have bigger problems. gettimeofday() can result in incorrect timings if there are processes on your system that change the timer (ie, ntpd). On a "normal" linux, though, I believe the resolution of gettimeofday() is 10us. It can jump forward and backward and time, consequently, based on the processes running on your system. This effectively makes the answer to your question no.

You should look into clock_gettime(CLOCK_MONOTONIC) for timing intervals. It suffers from several less issues due to things like multi-core systems and external clock settings.

Also, look into the clock_getres() function.

High Resolution, Low Overhead Timing for Intel Processors

If you're on Intel hardware, here's how to read the CPU real-time instruction counter. It will tell you the number of CPU cycles executed since the processor was booted. This is probably the finest-grained counter you can get for performance measurement.

Note that this is the number of CPU cycles. On linux you can get the CPU speed from /proc/cpuinfo and divide to get the number of seconds. Converting this to a double is quite handy.

When I run this on my box, I get

1186792787948473211867927879692217it took this long to call printf: 207485

Here's the Intel developer's guide that gives tons of detail.

#include <stdio.h>#include <stdint.h>inline uint64_t rdtsc() {    uint32_t lo, hi;    __asm__ __volatile__ (      "xorl %%eax, %%eax\n"      "cpuid\n"      "rdtsc\n"      : "=a" (lo), "=d" (hi)      :      : "%ebx", "%ecx");    return (uint64_t)hi << 32 | lo;}main(){    unsigned long long x;    unsigned long long y;    x = rdtsc();    printf("%lld\n",x);    y = rdtsc();    printf("%lld\n",y);    printf("it took this long to call printf: %lld\n",y-x);}

@Bernard:

I have to admit, most of your example went straight over my head. It does compile, and seems to work, though. Is this safe for SMP systems or SpeedStep?

That's a good question... I think the code's ok.From a practical standpoint, we use it in my company every day,and we run on a pretty wide array of boxes, everything from 2-8 cores.Of course, YMMV, etc, but it seems to be a reliable and low-overhead(because it doesn't make a context switch into system-space) methodof timing.

Generally how it works is:

• declare the block of code to be assembler (and volatile, so theoptimizer will leave it alone).
• execute the CPUID instruction. In addition to getting some CPU information(which we don't do anything with) it synchronizes the CPU's execution bufferso that the timings aren't affected by out-of-order execution.
• execute the rdtsc (read timestamp) execution. This fetches the number ofmachine cycles executed since the processor was reset. This is a 64-bitvalue, so with current CPU speeds it will wrap around every 194 years or so.Interestingly, in the original Pentium reference, they note it wraps around every5800 years or so.
• the last couple of lines store the values from the registers intothe variables hi and lo, and put that into the 64-bit return value.

Specific notes:

• out-of-order execution can cause incorrect results, so we execute the"cpuid" instruction which in addition to giving you some informationabout the cpu also synchronizes any out-of-order instruction execution.

• Most OS's synchronize the counters on the CPUs when they start, sothe answer is good to within a couple of nano-seconds.

• The hibernating comment is probably true, but in practice youprobably don't care about timings across hibernation boundaries.

• regarding speedstep: Newer Intel CPUs compensate for the speedchanges and returns an adjusted count. I did a quick scan oversome of the boxes on our network and found only one box thatdidn't have it: a Pentium 3 running some old database server.(these are linux boxes, so I checked with: grep constant_tsc /proc/cpuinfo)

• I'm not sure about the AMD CPUs, we're primarily an Intel shop,although I know some of our low-level systems gurus did anAMD evaluation.

Hope this satisfies your curiosity, it's an interesting and (IMHO)under-studied area of programming. You know when Jeff and Joel weretalking about whether or not a programmer should know C? I wasshouting at them, "hey forget that high-level C stuff... assembleris what you should learn if you want to know what the computer isdoing!"