m2-internship/report
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Correct §5

Browse source
This commit is contained in:
Théophile Bastian 2018-08-08 14:29:04 +02:00
parent 9e09921c2a
commit fbb68ba2cf
2 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
report/TODO
View file

@ -1,2 +1 @@
- Make consistant -ise / -ize (eg. optimize)
- Add references to all my repositories - Add references to all my repositories

29
report/report.tex
View file

@ -1014,14 +1014,15 @@ Table~\ref{table:bench_time}.
\caption{Time benchmarking on hackbench}\label{table:bench_time} \caption{Time benchmarking on hackbench}\label{table:bench_time}
\end{table} \end{table}
The performance of \ehelfs{} is probably overestimated, since \ehelfs{} do not The performance of \ehelfs{} is probably overestimated for a production-ready
handle all registers from the original DWARF file, and thus the version, since \ehelfs{} do not handle all registers from the original DWARF
\prog{libunwind} version must perform more computation. However, this overhead, file, and thus the \prog{libunwind} version must perform more computation.
although impossible to measure without first implementing supports for every However, this overhead, although impossible to measure without first
register, would probably not be that big, since most of the time is spent implementing supports for every register, would probably not be that big, since
finding the relevant row. Support for every DWARF instruction, however, would most of the time is spent finding the relevant row. Support for every DWARF
not slow down at all the implementation, since every instruction would simply instruction, however, would not slow down at all the implementation, since
be compiled to x86\_64 without affecting the already supported code. every instruction would simply be compiled to x86\_64 without affecting the
already supported code.
It is also worth noting that on the machine described in It is also worth noting that on the machine described in
Section~\ref{ssec:bench_hw}, the compilation of the \ehelfs{} at a level of Section~\ref{ssec:bench_hw}, the compilation of the \ehelfs{} at a level of
@ -1176,13 +1177,13 @@ only concerned about the columns CFA, \reg{rip}, \reg{rsp}, \reg{rbp} and
second row analyzes all the columns that were encountered, no matter whether second row analyzes all the columns that were encountered, no matter whether
supported or not. supported or not.
The Table~\ref{table:instr_types} analyzes the proportion of each command The Table~\ref{table:instr_types} analyzes the proportion of each command (\ie\
(\ie\ the formal way a register is set) for non-CFA columns in the sampled the formal way a register is set) for non-CFA columns in the sampled data. For
data. For a brief explanation, \texttt{Offset} means stored at offset from CFA, a brief explanation, \texttt{Offset} means stored at offset from CFA,
\texttt{Register} means the value from a machine register, \texttt{Expression} \texttt{Register} means the value from a machine register, \texttt{Expression}
means stored at the value of an expression, and the \texttt{Val\_} prefix means means stored at the address of an expression's result, and the \texttt{Val\_}
that the value must not be dereferenced. Overall, it can be seen that prefix means that the value must not be dereferenced. Overall, it can be seen
supporting \texttt{Offset} already means supporting the vast majority of that supporting \texttt{Offset} already means supporting the vast majority of
registers. The data gathered (not reproduced here) also suggests that registers. The data gathered (not reproduced here) also suggests that
supporting a few common expressions is enough to support most of them. supporting a few common expressions is enough to support most of them.