Print indd

3.2
Running the Simulation
After the analysis step finished gathering the information needed from the pro-
gram, the simulator can be started. It is written in SystemC and connected to
gem5 using the works of Menard et al. [
11
] to connect TLM (Transaction Level
Modeling) compatible modules. This allows more flexibility with custom periph-
ery that might be used in conjunction with other processor simulators. Thus in
the future, the whole memory hierarchy and some more complex devices can
be exchanged with more accurate or faster models. As a result, not only the
microarchitecture but also the connected parts of a platform can be taken into
account during loop executions. Most simulation models support connecting to
SystemC or even TLM compatible modules.
For the simulation, the O3 model and the Timing Simple (TS) model of gem5
are used. O3 is an implementation of a complex out-of-order pipeline originally
based on the Alpha CPUs. It is cycle accurate and as such the reference for
the highest possible accuracy and the slowest simulation speed. TS implements
an instruction accurate processor model that typifies the most inaccurate but
fastest possible simulation.
First attempts showed that it is insignificant whether to use the O3 or the
TS model outside of loops. The simulation time and the estimated time are only
slightly affected. This confirms our assumption that programs remain most of
their time within loops. At the beginning, the implemented simulation starts

---

90
S. Rachuj et al.
with an active O3 model to reduce the overhead of switching from TS to O3
when entering a loop.
Keeping track of the currently executed instruction is done by using the
tracing functionality of gem5. It logs the committed instructions in the correct
order. With the help of the information gathered during the analysis of the
program, the basic block of each finished instruction can be found. Whenever
the next basic block is reached, the simulation host updates some statistics of the
left basic block like the number of its executions and the required estimated time.
The latter is tracked for the simulation of each model separately. Additionally,
it is checked whether the basic block is the head of an outer loop or, in case a
loop was already entered, if the block is still part of the loop. According to the
results of these checks, the model is switched accordingly.
The default tracing implementation of gem5 does not log instructions that
result in an exception. This behavior is not suitable for the methodology since
the knowledge of where the exception occurred is required. Hence, when only
relying on the tracing implementation, it is difficult to track which instruction
is responsible for the fault. Adding support for tracing these instructions can be
achieved by some minor adjustments preventing gem5 from removing the created
log data structures in the case of an exception.
For each committed instruction, gem5 writes a line to a C++ stream which
can be intercepted by providing an output stream with a custom stream buffer.
Parsing the lines allows the extraction of the program counter and the corre-
sponding disassembled instruction. This information is used as described above
to find the basic block belonging to the logged line and to keep the statistics
up to date.
As soon as a head block of a loop reaches a manually configurable number of
executions, the O3 model is replaced by the TS model. This increases the speed
of the remaining iterations significantly. When the loop is left, the O3 model
takes the simulation over again. In case the loop is executed again (e.g. due to
being inside a function called multiple times from sequential code), the models
are switched directly at the beginning since enough runtime information was
already gathered at the first time.
Changing the model from O3 to TS and backwards is based on functionality
of gem5 that was initially intended for checkpointing. To exchange the models,
a so-called “drain” can be requested. This leads to gem5 notifying all of its
components to come to a consistent state that can safely be serialized, e.g. for
writing it into a file as it is done by the checkpointing implementation. Until
all components are drained, some further cycles must be emulated since the
processor needs to commit all instructions still residing in the pipeline. When
the process is finished, the CPU models are exchanged with the help of functions
already built into gem5 and the simulation is continued. Enabling a switched
out model again works in the same way just with interchanged roles. Due to
the latency required by the drain implementation, it is not possible to exchange
the simulators exactly at the beginning of a new iteration. Predicting when the
draining is completed is also not practicable since the number of cycles depend

---

A Hybrid Approach for Runtime Analysis
91
on the current state of the pipeline. That is why an execution of a basic block
is only considered completely accurate, if the O3 model was active from the
beginning to the end of the block. Otherwise it is considered inaccurate and not
used for the runtime estimation.
After the simulation has come to an end, a correcting calculation of the
estimated runtime using the statistics gathered during the run is performed.
The following variables for each basic block
k are available:
n
C,k
Amount of times basic block
k was reached during the simulation using
the O3 (cycle accurate) model.
n
I,k
Amount of times basic block
k was reached during the simulation using the
TS (instruction accurate) model.
t
C,k
Cumulative simulated time of basic block
k during the simulation using the
O3 (cycle accurate) model.
t
I,k
Cumulative simulated time of basic block
k during the simulation using the
TS (instruction accurate) model.
Equation (
1
) shows the computation used for estimating the global estimated
runtime
t from these variables. Basic blocks never executed in O3 mode are
handled in the else case. Their runtime estimation is equivalent to the instruction
accurate simulation. For the other basic blocks the estimated time for one cycle
accurate iteration is taken and multiplied by the number of times the block was
reached during the run.
t =

k

t
C,k
n
C,k
· (n
C,k
+
n
I,k
)
if
n
C,k
> 0
t
I,k
else
(1)
By tracking the statistics for each basic block with the help of the tracing
functionality and the previously gathered control flow information, a change in
the runtime behavior of the following loop iterations is correctly respected by the
estimation. However, this is only true if there is no or only a similar fluctuation
during the inaccurate execution. This is the main weakness of the methodology.
In the future, implementing a mechanics for finding great discrepancies during
a loop can allow switching back to the accurate model to solve this issue.