Best, most accurate clock?

Started by
30 comments, last by Ademan555 20 years ago
AP: agreed. Gets even better when you expect the results to be good to n units, yet your method of getting the timestamp takes several multiples of n

Oh bother. Wish I had found that while researching my timer, would have saved some time I wrote up another article about this, which also covers timer peculiarities, but looks to their hardware implementations to see why.
E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3
Advertisement
Hello all,

Following program reports that 536 clockcycles have elapsed between the first rdtsc and the second rdtsc. This looks like a lot of cycles to me...

I ran the test on a 2.4 Ghz PIV under Suse Linux 8.0, gcc 3.3. Results are the same for O1 and O2. O0 returns 576 and O3 messes up... .

Intel 7.0 for Linux compiler reports 560 cycles under O0.
O1, O2 and O3 return garbage on Intel.
Am I doing something wrong here?

- Kurt

P.S. I tried some warming up by calling the rdtsc/cpuid sequence multiple times, but that didn''t make any difference... .
----
#define rdtscll(x)\
__asm__ __volatile__ ("rdtsc" : "=A" (x))
#define cpuid __asm__ __volatile__ (".byte 0x0f, 0xa2" : : : "eax", "ebx", "ecx", "edx"

int main()
{
unsigned cycles1, cycles2;
cycles1=0;
cycles2=0;

cpuid;
rdtscll(cycles1);
cpuid;
rdtscll(cycles2);

cout << cycles2-cycles1 << "\n";
}

This topic is closed to new replies.

Advertisement