Question

Is there a way using C or assembler or maybe even C# to get an accurate measure of how long it takes to execute a ADD instruction?

Answer 1

Yes, sort of, but it’s non-trivial and produces results that are almost meaningless, at least on most reasonably modern processors.

On relatively slow processors (e.g., up through the original Pentium in the Intel line, still true on most small embedded processors) you can just look in the processor’s data sheet and it’ll (normally) tell you how many clock ticks to expect. Quick, simple, and easy.

On a modern desktop machine (e.g., Pentium Pro or newer), life isn’t nearly that simple. These CPUs can execute a number of instructions at a time, and execute them out of order as long as there aren’t any dependencies between them. This means the whole concept of the time taken by a single instruction becomes almost meaningless. The time taken to execute one instruction can and will depend on the instructions that surround it.

That said, yes, if you really want to, you can (usually — depending on the processor) measure something, though it’s open to considerable question exactly how much it’ll really mean. Even getting a result like this that’s only close to meaningless instead of completely meaningless isn’t trivial though. For example, on an Intel or AMD chip, you can use RDTSC to do the timing measurement itself. That, unfortunately, can be executed out of order as described above. To get meaningful results, you need to surround it by an instruction that can’t be executed out of order (a “serializing instruction”). The most common choice for that is CPUID, since it’s one of the few serializing instructions that’s available to “user mode” (i.e., ring 3) programs. That adds a bit of a twist itself though: as documented by Intel, the first few times the processor executes CPUID, it can take longer than subsequent times. As such, they recommend that you execute it three times before you use it to serialize your timing. Therefore, the general sequence runs something like this:

.align 16
CPUID
CPUID
CPUID
RDTSC
; sequence under test
Add eax, ebx
; end of sequence under test
CPUID
RDTSC

Then you compare that to a result from doing the same, but with the sequence under test removed. That’s leaving out quite a fe details, of course — at minimum you need to:

1. set the registers up correctly before each CPUID
2. save the value in EAX:EDX after the first RDTSC
3. subtract result from the second RDTSC from the first

Also note the “align” directive I’ve inserted — instruction alignment can and will affect timing as well, especially if a loop is involved.