The currently recommended interface for high-rez time on Linux (and POSIX in general) is clock_gettime. See the man page.
clock_gettime(CLOCK_REALTIME, struct timespec *tp) // for wall-clock time
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, struct timespec *tp) // for CPU time
But read the man page. Note that you need to link with -lrt, because POSIX says so, I guess. Maybe to avoid symbol conflicts in -lc, for old programs that defined their own clock_gettime? But dynamic libs use weak symbols...
The best sleep function is nanosleep. It doesn t mess around with signals or any crap like usleep. It is defined to just sleep, and not have any other side effects. And it tells you if you woke up early (e.g. from signals), so you don t necessarily have to call another time function.
Anyway, you re going to have a hard time testing one rep of something that short that involves a system call. There s a huge amount of opportunity for variation. e.g. the scheduler may decide that some other work needs doing (unlikely if your process just started; you won t have used up your timeslice yet). CPU cache (L2 and TLB) are easily possible.
If you have a multi-core machine and a single-threaded benchmark for the code you re optimizing, you can give it realtime priority pinned to one of your cores. Make sure you choose the core that isn t handling interrupts, or your keyboard (and everything else) will be locked out until it s done. Use taskset (for pinning to one CPU) and chrt (for setting realtime prio).
See this mail I sent to gmp-devel with this trick:
http://gmplib.org/list-archives/gmp-devel/2008-March/000789.html
Oh yeah, for the most precise timing, you can use rdtsc yourself (on x86/amd64). If you don t have any other syscalls in what you re benching, it s not a bad idea. Grab a benchmarking framework to put your function into. GMP has a pretty decent one. It s maybe not set up well for benchmarking functions that aren t in GMP and called mpn_whatever, though. I don t remember, and it s worth a look.
