This chapter describes a sample session when using some of the
instrumentation tools. Refer to the command descriptions for details
on each individual command.
As a basis for this example, the
Coremark www.eembc.org/coremark/ benchmark
will be run and analyzed in Simics. The source code is downloadable
with an Apache license and very easy to compile and run.
In this example Coremark will be run on a x86 QSP system running
Linux.
The Coremark binary was compiled on standard x86 Linux host system
and in this example we are using the simics-agent to transfer
the binary to the target system.
The script in figure 12 shows
how the binary is uploaded to the target, enabling instrumentation
only for the coremark executable and starting coremark and
waiting for it to be finished.
In this setup four instrumentation tools are enabled:
- An instruction histogram which takes a look at each
instruction being executed and analyzes the x86 disassembly
string. Registers such as EAX, EDX are replaced with "r32"
indicating they operating on a normal 32 bit
registers. Similarly immediate values are replaced with an "imm"
marker.
- Another instruction histogram which instead groups the
instructions by their instruction sizes in bytes.
- An x86 branch-profiler tool which monitors common branch
instructions and checks if conditional branches take the jumps
of falls-through.
- A memory profiler which monitors all instruction and data
accesses from the processor and keeps track of how many
reads/writes and executes there are on each logical memory
location being accessed.
The instrumentation data gathered by these tools will be analyzed a
bit in the next chapters. To get a bit more readable big numbers,
the following commands splits the numbers with underscores
on logical units; digit-grouping 10 3 for decimal
values and digit-grouping 16 4 for hexadecimal
values.
First lets take a look of which instructions that are most commonly
executed shown in figure 13.
Here the 10 most commonly executed instruction combination is
listed. A total of 425 different instruction variants was
identified when running the coremark benchmark. With 10,000
iterations in coremark, roughly 3 billion instructions was executed
in total.
SSE registers are marked as x128 in the disassembly, lets see if any
of these where executed in figure 14.
So a few instructions, but they are not used in the body of the
benchmark at all, since they are executed so few times.
Now lets investigate the instruction sizes of the executed
instructions, which is gathered by the other instruction-histogram
shown in figure 15.
Three byte instructions are by far the most common instruction
size when executing this benchmark.
The branch-profiler will report more details on the
branch instructions shown in figure 16.
Here we see the most commonly used branch instruction with information
if the branches were taken or not. Unconditional jumps, of course,
always jumps.
Finally, we can get instruction information from the memory-profiler
shown in figure 17.
Here we can see where we have executed most, using the logical addresses.
By default, the range between start and stop is set to 4K, but this can
be controlled through a command argument. So the coremark binary executed
on a total of 90 4K pages, but 99.9% of its execution was only in three
pages.
The memory-profiler will count the first byte of an instruction as executed.
So if we decrease the granularity to just one byte shown in figure
18.
This produces the top-list of the most executed instruction of the
benchmark. A total of 12542 unique instructions (in memory) have
been executed.
For the same coremark run, now examine a bit on how many data
accesses that happened, using the memory-profile tool again
shown in figure 19.
Here we can see that the reads to memory is pretty much only
associated to one heap-page, and one stack-page. The memory-profiler
here annotates each byte as being read. So if the software performs a 32 bit
read, the four bytes will all have an increased counter.
The similar for command for write-accesses is shown in figure
20.
Not very surprisingly, the writes goes to the same two pages, but
writes are less frequent than reads.
And finally say that we are interested in the distribution of the writes on the most
commonly read stack-page, this is shown in figure 21.
In this case we listed the addresses in address-order using the
granularity of 128 bytes.
granularity = 128 sort-on-column = Start ┌─────┬────────────────┬────────────────┬───────────┐ │Row #│ Start │ Stop │ Count │ ├─────┼────────────────┼────────────────┼───────────┤ │ 1│0x7fff_15e5_e000│0x7fff_15e5_e07f│ 700│ │ 2│0x7fff_15e5_e080│0x7fff_15e5_e0ff│ 9_029│ │ 3│0x7fff_15e5_e100│0x7fff_15e5_e17f│ 14_585│ │ 4│0x7fff_15e5_e180│0x7fff_15e5_e1ff│ 17_138│ │ 5│0x7fff_15e5_e200│0x7fff_15e5_e27f│ 10_315│ │ 6│0x7fff_15e5_e280│0x7fff_15e5_e2ff│414_573_166│ │ 7│0x7fff_15e5_e300│0x7fff_15e5_e37f│171_369_107│ │ 8│0x7fff_15e5_e380│0x7fff_15e5_e3ff│ 56_832_627│ │ 9│0x7fff_15e5_e400│0x7fff_15e5_e47f│ 1_004_298│ │ 10│0x7fff_15e5_e480│0x7fff_15e5_e4ff│ 2_681_185│ │ 11│0x7fff_15e5_e500│0x7fff_15e5_e57f│ 746│ │ 12│0x7fff_15e5_e580│0x7fff_15e5_e5ff│ 408│ │ 13│0x7fff_15e5_e600│0x7fff_15e5_e67f│ 240│ │ 14│0x7fff_15e5_e680│0x7fff_15e5_e6ff│ 220│ │ 15│0x7fff_15e5_e700│0x7fff_15e5_e77f│ 76│ │ 16│0x7fff_15e5_e780│0x7fff_15e5_e7ff│ 98│ ├─────┼────────────────┼────────────────┼───────────┤ │Sum │ │ │646_513_938│ └─────┴────────────────┴────────────────┴───────────┘