23 lines
1.7 KiB
TeX
23 lines
1.7 KiB
TeX
\section{Simulation Results}
|
|
\label{sec:simulation_results}
|
|
|
|
In this section the accuracy of the new simulation frontend will be evaluated.
|
|
After a short discussion about the general expections regarding the accuracy and considerations to make, the simulation results will be presented.
|
|
The presentation is structured into two parts:
|
|
At first simulation statistics of numerous benchmarks are compared against the gem5\cite{Binkert2011} simulator that uses detailed processor models and can be considered as a reference. .
|
|
Secondly, the new simulation frontend is compared against the memory access trace generator tool of the Ramulator DRAM simulator\cite{Ghose2019}.
|
|
|
|
\subsection{Accuracy}
|
|
Generating memory access traces using dynamic binary instrumentation as a faster alternative to the simulation of detailed processor models introduces several inaccuracies, which of some will now be enumerated.
|
|
|
|
The most important aspect to consider is that DBI can only instrument the target application but fails to also take the operating system the application is running on into account.
|
|
That includes the inability to observe the execution of kernel routines that are directly invoked by the target application through system calls, but also the preemtive scheduling of other programs that are running on the system at the same time.
|
|
|
|
What is also to concern is the fetching of the instructions itself:
|
|
In a real system the binary executable of the target application is placed in the DRAM, along with its data, and gets fetched into the instruction cache while executing.
|
|
Since the DBI cannot observe the fetching of those instructions, the new simulator frontend cannot model this memory traffic.
|
|
|
|
\subsection{Comparison to the gem5 Simulator}
|
|
|
|
|