In computers, hardware performance counters (HPC),[1] or hardware counters are a set of special-purpose registers built into modern microprocessors to store the counts of hardware-related activities within computer systems. Advanced users often rely on those counters to conduct low-level performance analysis or tuning.
The number of available hardware counters in a processor is limited while each CPU model might have a lot of different events that a developer might like to measure. Each counter can be programmed with the index of an event type to be monitored, like a L1 cache miss or a branch misprediction.
One of the first processors to implement such counter and an associated instruction [[X86 instruction listings#Added with Pentium MMX|RDPMC]]
to access it was the Intel Pentium, but they were not documented until Terje Mathisen wrote an article about reverse engineering them in Byte July 1994.[2]
The following table shows some examples of CPUs and the number of available hardware counters:
Processor | available HW counters | |
---|---|---|
UltraSparc II | 2 | |
Pentium III | 2 | |
ARM11 | 2 | |
AMD Athlon | 4 | |
IA-64 | 4 | |
ARM Cortex-A5 | 2[3] | |
ARM Cortex-A8 | 4 | |
ARM Cortex-A9 MPCore | 6 | |
POWER4 | 8 | |
Pentium 4 | 18 |
Compared to software profilers, hardware counters provide low-overhead access to a wealth of detailed performance information related to CPU's functional units, caches and main memory etc. Another benefit of using them is that no source code modifications are needed in general. However, the types and meanings of hardware counters vary from one kind of architecture to another due to the variation in hardware organizations.
There can be difficulties correlating the low level performance metrics back to source code. The limited number of registers to store the counters often force users to conduct multiple measurements to collect all desired performance metrics.
Modern superscalar processors schedule and execute multiple instructions out-of-order at one time. These "in-flight" instructions can retire at any time, depending on memory access, hits in cache, stalls in the pipeline and many other factors. This can cause performance counter events to be attributed to the wrong instructions, making precise performance analysis difficult or impossible.
AMD introduced methods to mitigate some of these drawbacks. For example, the Opteron processors have implemented [4] in 2007 a technique known as Instruction Based Sampling (or IBS). AMD's implementation of IBS provides hardware counters for both fetch sampling (the front of the superscalar pipeline) and op sampling (the back of the pipeline). This results in discrete performance data associating retired instructions with the "parent" AMD64 instruction.