59 lines
3.1 KiB
TeX
59 lines
3.1 KiB
TeX
|
\chapter*{Wrapping it all up?}\label{chap:wrapping_up}
|
||
|
|
|
||
|
|
In \autoref{chap:palmed}, we introduced \palmed{}, a framework to build a
|
||
|
|
backend model. Following up in \autoref{chap:frontend}, we introduced a
|
||
|
|
frontend model for the ARM-based Cortex A72 processor. Then, in
|
||
|
|
\autoref{chap:staticdeps}, we further introduced a dependency detection model.
|
||
|
|
|
||
|
|
Put together, these three parts cover the major bottlenecks that a code
|
||
|
|
analyzer must take into account. It would thus be satisfying to conclude this
|
||
|
|
manuscript with a unified tool packing the three together, and evaluating the
|
||
|
|
full extent of this PhD against the state of the art.
|
||
|
|
|
||
|
|
\medskip{}
|
||
|
|
|
||
|
|
This is, sadly, not reasonably feasible without a good amount of engineering
|
||
|
|
effort and duct-tape code for multiple reasons.
|
||
|
|
|
||
|
|
\smallskip{}
|
||
|
|
|
||
|
|
First, the choice of the Cortex A72 as an architecture means relying on a
|
||
|
|
low-power processor and on the Raspberry Pi microcomputer for benchmarking
|
||
|
|
---~which has a low amount of RAM, a low-throughput storage and is prone to
|
||
|
|
overheating. This makes extensive benchmarking impractical.
|
||
|
|
|
||
|
|
There is also the heterogeneity of formats used to describe benchmarks. Some
|
||
|
|
tools, such as \staticdeps{}, rely on assembled objects and directly deal with
|
||
|
|
assembly. Some others use custom formats to describe assembly instructions and
|
||
|
|
their numerous declinations ---~for instance, the performance of \lstxasm{mov
|
||
|
|
\%rax, \%rbx} will be far from that of \lstxasm{mov 8(\%rax, \%r10), \%rbx},
|
||
|
|
despite being both a \texttt{mov} instruction. For one, \palmed{} uses such a
|
||
|
|
format, defined by \pipedream{} (its benchmarking backend), while \uopsinfo{}
|
||
|
|
uses a different one. Overall, this makes a challenge of using multiple tools
|
||
|
|
on the same code, and an even greater challenge of comparing the results
|
||
|
|
---~let alone pipelining them.
|
||
|
|
|
||
|
|
\bigskip{}
|
||
|
|
|
||
|
|
These models, however, should become really meaningful only when combined
|
||
|
|
together ---~or, even better, when each of them could be combined with any
|
||
|
|
other model of the other parts. To the best of our knowledge, however, no such
|
||
|
|
modular tool exists; nor is there any standardized approach to interact with
|
||
|
|
such models. The usual approach of the domain to try a new idea, instead, is to
|
||
|
|
create a full analyzer implementing this idea, such as what we did with \palmed{}
|
||
|
|
for backend models, or such as \uica{}'s implementation, focusing on frontend
|
||
|
|
analysis.
|
||
|
|
|
||
|
|
In hindsight, we advocate for the emergence of such a modular code analyzer.
|
||
|
|
It would maybe not be as convenient or well-integrated as ``production-ready''
|
||
|
|
code analyzers, such as \llvmmca{} ---~which is packaged for Debian. It could,
|
||
|
|
however, greatly simplify the academic process of trying a new idea on any of
|
||
|
|
the three main models, by decorrelating them. It would also ease the
|
||
|
|
comparative evaluation of those ideas, while eliminating many of the discrepancies
|
||
|
|
between experimental setups that make an actual comparison difficult ---~the
|
||
|
|
reason that prompted us to make \cesasme{} in \autoref{chap:CesASMe}. Indeed,
|
||
|
|
with such a modular tool, it would be easy to run the same experiment, in the
|
||
|
|
same conditions, while only changing \eg{} the frontend model but keeping a
|
||
|
|
well-tried backend model.
|
||
|
|
|