0
votes

I know that the unsigned long long gets stored in eax/edx but I'm wondering how can I find out how many clock cycles it takes to execute a single rdtsc instruction?

EDIT: Does something like this work?

.globl rdtsc

rdtsc:

rdtsc

movl %eax, %ecx

movl %edx, %ebx

rdtsc

subl %ecx, %eax

subl %ebx, %edx

ret

2
If this is a problem for you, then you aren't benchmarking your code properly. You need to run enough iterations so that the overhead of rdtsc() is negligible.Mysticial
The overhead of rdtsc has already been measured. See instlatx64.atw.huharold

2 Answers

1
votes

You could execute rdtsc repeatedly, and look at the difference between consecutive return values. Of course you need to bear in mind things like context switches etc, which will cause massive spikes.

See rdtsc, too many cycles for a discussion.

1
votes

Your code looks correct though you should run it several times and use the shortest value that comes up.

I think the question should be restated: what is the overhead of using rdtsc to count elapsed clock cycles during a code sequence. So the counting code is essentially (32-bit example):

rdtsc
mov dword ptr [mem64],eax
mov dword ptr [mem64+4],edx

; the code sequence to clock would go here when you're clocking it

rdtsc
sub eax,dword ptr [mem64]
sbb edx,dword ptr [mem64+4]    ; I always mix up sbb and sub so this may be incorrect

and the result is the practical elapsed time of the "rdtsc overhead" when timing a code sequence.

When you have subtracted the rdtsc overhead you need to factor in pipelining and if overlapping processing has completed. For me I assume that if the timed sequence runs in fewer than perhaps 30 cycles there may be uncompleted pipelining issues that need to be taken into account. If the sequence requires more than 100 cycles there may issues but they may be ignored.

So what about between 30 and 100? It's definitely gray.