Hi,

How do you measure time with a one cycle resolution? EpicTimer clearly does not cut it, and from what I gather
<https://www.intel.com/content/www/us/en/embedded/training/ia-32-ia-64-benchmark-code-execution-paper.html>, rdtsc cannot do it either. You need to have a CPU capable of understanding rdtscp.

But then, FPC 3.00 does not want to compile this assembly instruction. So how do you guys manage to measure it?

Thank you

wolf

FPC trunk supports rdtscp. And if you're using a FPC version that doesn't support an instruction, you can always hardcode it with 'db' (make sure you add a comment with the real instruction to keep your code readable), e.g:

db 0fh, 01h, 0f9h  { rdtscp - not supported by FPC 3.0's inline assembler }

Nikolay

Hi,

Wolf wrote

rdtsc cannot do it either. You need to have a CPU capable of understanding rdtscp. From what I understood, that doesn't give you cycles either, but only the same

timestamp intervals RDTSC returns.
Tangent: On Windows, RDTSC is wrapped by the QueryPerformanceCounter() call. QPC incidentally is complicated enough that it is very likely no out-of-order instructions are pending by the time it gets to actually executing RDTSC, but with less jitter than "abusing" CPUID for serialisation (QPC takes a rather stable 22 cycles). /Tangent

What I do to get cycle-accurate counts in microbenchmarks is first calibrate the timer with a known-cycle-length task, obtain a "timestamps per cylce" from that (depending on core clock, usually between 200 and 1300), and then measure the actual function. Note that depending on how well you can control multitasking, interrupts and power management, you will need thousands to millions of repeats of the function under test to be reasonably free from artefacts. Looks a bit statistical, but it's precise enough to actually see the instruction cache, instruction alignment and branch can also validate Agner Fog's Instruction Timing Tables with it, so it can't be that bad ;-)

In our previous episode, Martok said:

Afaik Query* also works reliable on systems with multiple processors. Might be important now that Ryzen is a multiple die solution.

Yes, that's AT&T asm syntax. FPC supports both AT&T and Intel syntax modes with the {$asmmode} directive:

https://www.freepascal.org/docs-html/prog/progsu3.html

AT&T is the default for historical reasons, but Intel also works fine.

Nikolay