Take the 2-minute tour ×


BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
    gettimeofday(&currentTimeVal, NULL);
    performanceCount->QuadPart = (currentTimeVal.tv_sec - startTimeVal.tv_sec);
    performanceCount->QuadPart *= (1000 * 1000);
    performanceCount->QuadPart += (currentTimeVal.tv_usec - startTimeVal.tv_usec);

    return true;


share|improve this question
add comment

10 Answers

up vote 37 down vote accepted



Also, look into the clock_getres() function.

share|improve this answer
clock_gettime is present only on newest Linux. other system have only gettimeofday() –  vitaly.v.ch Dec 18 '09 at 16:21
clock_gettime was included in POSIX in 2001. as far as I know currently clock_gettime() implemented in Linux 2.6 and qnx. but linux 2.4 is currently used in many production systems. –  vitaly.v.ch Jun 25 '10 at 12:07
It was introduced in 2001, but not mandatory until POSIX 2008. –  R.. Jan 16 '11 at 23:02
From the Linux FAQ for lock_gettime (see David Schlosnagle's answer) "CLOCK_MONOTONIC...is frequency adjusted by NTP via adjtimex(). In the future (I'm still trying to get the patch in) there will be a CLOCK_MONOTONIC_RAW that will not be modified at all, and will have a linear correlation with the hardware counters." I don't think the _RAW clock ever made it into the kernel (unless it was renamed _HR, but my research suggests that efforts being abandonned too). –  Tony D Jun 15 '11 at 6:16
add comment

High Resolution, Low Overhead Timing for Intel Processors



When I run this on my box, I get

it 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"
      : "%ebx", "%ecx");
    return (uint64_t)hi << 32 | lo;

    unsigned long long x;
    unsigned long long y;
    x = rdtsc();
    y = rdtsc();
share|improve this answer
The TSC on Core and above Intel platforms is synchronized across multiple CPUs and increments at a constant frequency independent of power management states. See Intel Software Developer’s Manual, Vol. 3 Section 18.10. However the rate at which the counter increments is not the same as the CPU's frequency. The TSC increments at “the maximum resolved frequency of the platform, which is equal to the product of scalable bus frequency and maximum resolved bus ratio” Intel Software Developer’s Manual, Vol. 3 Section 18.18.5. You get those values from the CPU's model-specific registers (MSRs). –  sstock Jul 15 '09 at 7:26
You can obtain the scalable bus frequency and maximum resolved bus ratio by querying the CPU’s model-specific registers (MSRs) as follows: Scalable bus frequency == MSR_FSB_FREQ[2:0] id 0xCD, Maximum resolved bus ratio == MSR_PLATFORM_ID[12:8] id 0x17. Consult Intel SDM Vol.3 Appendix B.1 to interpret the register values. You can use the msr-tools on Linux to query the registers. kernel.org/pub/linux/utils/cpu/msr-tools –  sstock Jul 15 '09 at 7:32
Shouldn't your code use CPUID again after the first RDTSC instruction and before executing the code being benchmarked? Otherwise, what's to stop the benchmarked code being executed before/in-parallel-with the first RDTSC, and consequently underrepresented in the RDTSC delta? –  Tony D Jun 15 '11 at 5:54
add comment




Generally how it works is:


Specific notes:







share|improve this answer
... The kernel people have been trying to get people to stop using rdtsc for a while... and generally avoid using it in the kernel because it's just that unreliable. –  Spudd86 Jun 14 '10 at 20:27
For reference, the question I asked (In a separate reply -- before comments) was: "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?" –  Bernard Jan 22 '11 at 23:30
add comment




share|improve this answer
Thanks, this is very useful. –  ttvd Nov 29 '09 at 16:15
Thats just horrible. –  stefan Jan 28 '11 at 4:46
add comment




share|improve this answer
So what happens in your code when gettimeofday() jumps forward or backward with daylight savings? –  mpez0 Nov 13 '08 at 13:38
@mpez0 it doesn't –  Spudd86 Jun 14 '10 at 20:36
add comment



share|improve this answer
add comment

This answer mentions problems with the clock being adjusted. Both your problems guaranteeing tick units and the problems with the time being adjusted are solved in C++11 with the <chrono> library.

The clock std::chrono::steady_clock is guaranteed not to be adjusted, and furthermore it will advance at a constant rate relative to real time, so technologies like SpeedStep must not affect it.

You can get typesafe units by converting to one of the std::chrono::duration specializations, such as std::chrono::microseconds. With this type there's no ambiguity about the units used by the tick value. However, keep in mind that the clock doesn't necessarily have this resolution. You can convert a duration to attoseconds without actually having a clock that accurate.

share|improve this answer
add comment


share|improve this answer
add comment



share|improve this answer
add comment

Your Answer


