![]() | Profiling Methods |
Prev | Introduction | Next |
Exact measurement of time passed by or events happening in the execution of a code region (e.g. a function) needs additional measurement code to be inserted before and after the given region. This code reads the time or a global event count, and calculates differences. Thus, the original code has to be changed before execution. This is called instrumentation. Instrumentation can be done by the programmer itself, the compiler, or by the runtime system. As interesting regions usually are nested, the overhead of measurement always influences the measurement itself. Thus, instrumentation should be done selectively and results have to be interpreted with care. Of course, this makes performance analysis by exact measurement a very complex process.
Exact measurement is possible because of hardware counters (including counters incrementing on a time tick) provided in modern processors, which are incremented whenever an event is happening. As we want to attribute events to code regions, without the counters, we would have to handle every event by incrementing a counter for the current code region ourself. Doing this in software of course is not possible. But on the assumption that the event distribution over source code is similar when looking only at every n-th event instead of every event, we have constructed a measurement method which is tunable regarding overhead. It is called Sampling. Time Based Sampling (TBS) is using a timer to regularily look at the program counter to create a histogram over the program code. Event Based Sampling (EBS) is exploiting the hardware counters of modern processors, and is using a mode where an interrupt handler is called on counter underflow, generating a histogram of the corresponding event distribution. In the handler, the event counter is always reinitialized to the n of the sampling method. Advantage of sampling is that the code does not have to be changed, but it is still a compromise: the above assumption will be more correct if n is small, but the smaller the n, the higher the overhead of the interrupt handler.
Yet another measurement method is to simulate things happening in the computer system when executing a given code, i.e. execution driven simulation. Of course, the simulation is always derived from a more or less accurate machine model. For very detailed models approximating reality, the simulation time can be unacceptable high for practice. Advantage is that arbitrary complex measurement/simulation code can be inserted in a given code without perturbing results. Doing this directly before execution (called runtime instrumentation), using the original binary, is very comfortable for the user. The method becomes usuable when simulating only parts of a machine with a simple model. Besides, results produced by simple models often are way easier to understand: the problem with real hardware often is that results include overlapping effects from different parts of the machine.
Prev | Home | Next |
Introduction | Up | Profiling Tools |