Several classes of applications expose a set of parameters that in uence their extra-functional properties, such as the quality of the result or the size of the output. This leads the application designer to tune these parameters in order to nd the con guration that produces the desired outcome. From the architectural point of view, the trend in modern systems is to expose an high level of parallelism, often involving heterogeneous resources. To exploit the full potential of the hardware, the application designer must take into account resource-related parameters in the tuning process as well. Since the requirements of the applications and the resources assigned to each application might change at runtime, we argue that nding a one- t-all con guration is not a trivial operation. For this reason we use a framework that enhances an application with an adaptation layer in order to continuously tune the parameters of the application according to the evolving situation, in a best e ort fashion.
One of the main tasks of an application designer is to reach the required performance on the target system. Unfortunately, the performance of an application is seldom de ned by one metric, such as the execution time or its throughput. The performance is instead composed by a collection of metrics that are usually in contrast between them; for instance the time spent on elaborating the input against the quality of the result or the power consumption.
A common approach is to write an algorithm that exposes a set of parameters,
also known as dynamic knobs [
Since the application requirements may change at runtime { for instance if the platform is at rst powered by a battery, then plugged in a power supply { and the system might vary the resources allocated to the application as well, we argue that is not trivial to select a priori one- t-all con guration.
For this reason we rely on the argo1 framework[
The main idea of the framework is to exploit design time knowledge of the application, obtained through a DSE, to select the best con guration according to the actual application requirements and the observed performance, both of them composed by a collection of metrics of interest.
argo is implemented as an external library to be linked against the target application. It takes autonomous decision without interacting with any other element. For these reasons we are able to minimize the intrusiveness of the integration, expressed in terms of lines of code to be changed.
AS-RTM Static Goals
1 The name argo, has been borrowed by Greek mythology. argo was the ship on
which Jason and the Argonauts sailed to retrieve the Golden Fleece. As that boat was
a means for achieving the Golden Fleece (their goal): it aims at letting applications
to reach their goals too.
cation (Monitor element). argoships with a monitor suite to observe the most
common metrics:
{ The elapsed time or the application throughput.
{ The resident set size of the virtual memory that the process is using.
{ The process- and system-wide CPU usage.
{ Low-level metrics exposed by the widely adopted PAPI framework[
Moreover, to observe application-speci c metrics, such as the quality-related ones, the object-oriented implementation enable the application designer to easily integrate a custom monitor, de ning the methods that actually gather the new data.
On the other side, argoembeds the design time knowledge in the list of
Operating Points (OPs), where each OP represents a con guration and the
performance reached by the application using that con guration. The framework
is agnostic about the technique used to perform the DSE, in the current
implementation it parses the MULTICUBE[
The Application-Speci c RunTime Manager is the main component of the framework that selects the best con guration (Plan element), within the list of OPs, according to a multi-objective constrained optimization that might involve observed metrics (using Goals) or design time computed metrics (using Static Goals).
Since the dynamic knobs are heavily application-dependent, is the application itself that is in charge to apply the con guration selected by argo(Execute element), closing the MAPE loop. In this way it is possible to deploy the framework in a wide range of applications, while minimizing the integration e ort. In fact, we model the application as a sequence of di erent blocks of code that perform the elaboration iteratively. The idea is that at the beginning of each iteration, the application retrieves the con guration to use in the current iteration. 3
To employ separation of concerns, our work ow is based on three kind of les. The source code of the application describes the functional behavior, while we use two con guration les written in XML to express the adaptation layer: one le describes the design time knowledge and the third one describes the monitor infrastructure and the multi-objective optimization. argouses a tool that automatically generates the glue-code required to integrate the framework in the target application.
To better clarify the required e ort, Figure 2 provides an integration example considering a toy application. It shows the original source code written in black, while the integration code required to adopt argo is written in bold red. The application itself is very simple: on lines 9-16 the elaboration block, named \foo", performs the loop over the available jobs, while the function do job (line 14) actually performs the computation. 1 #include ``argo.hpp'' 2 3 int p a r a m ;
argo :: init () ;
In this example, we suppose that the elaboration is in uenced by the parameter param, expressing the amount of processed data and representing the software knobs of the application. Since the code of toy application expose directly the elaboration loop, the integration requires only to include the created header le, initialize the framework and then wrap the execution call with the generated macro, highlighted in bold red. In this way the framework is able to observe and tune the elaboration block. Since no assumptions are made on the structure of the application code, the tool generates a hierarchy of methods to interact with the application, that requires to write the glue-code using more ne grained functions. In the worst case, the application designer is able to directly use the framework API. 4
In this work we have described a framework that enhances an application with an adaptation layer. In particular it adapts the knowledge base obtained at design time with the information gathered by the monitor infrastructure. Using this information, argo selects the best con guration according to the actual requirement of the application.