|
|
|
A user interface is provided where the user can select the applications for analysis and see the results as well as the recommendations that are produced by the Energy Toolbox. Requests from the front-end are sent to the back-end in order to specify the microservices that will be executed. The UI is part of the SDK4ED platform. As a result, its implementation belongs to the integration of the individual toolboxes in a single application and is still under development. The following Figures present the preliminary version of the energy toolbox GUI.
|
|
|
|
A user interface is provided where the user can select the applications for analysis and see the results as well as the recommendations that are produced by the Energy Toolbox. Requests from the front-end are sent to the back-end in order to specify the microservices that will be executed. This Section presents the Energy Toolbox GUI.
|
|
|
|
On SDK4ED project selection, the only optional parameter that the user can provide in the “Extra Info by Toolbox” text field for the Energy Toolbox is
|
|
|
|
```
|
|
|
|
{“commit”:commit-id}
|
|
|
|
```
|
|
|
|
only if a certain commit of the project under analysis is needed to be analysed and stored in the database.
|
|
|
|
On the Energy Toolbox page, the user can select to perform a New analysis or retrieve the results of the Last analysis from the database:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Figure above displays the user interface for project-related information. As has been already stated, this panel shall be deprecated once the whole SDK4ED platform has been integrated and user and project management has been centralised. The backend will then automatically query the main integration module for user and project related information.
|
|
|
|
“New/Last analysis” is used to start a new analysis or to display the profiling results of the last analysis performed.
|
|
|
|
Developers can specify the scale of the analysis, by selecting “Full Analysis” for profiling the application to report all indicators or to choose a specific analysis (eg. hotspots indication, static analysis). The selection depends on the availability of the accelerator, developer preferences and priorities, etc.
|
|
|
|
The user can also select the Analysis Scale using the drop-down menu:
|
|
|
|
|
|
|
|
The following image shows one of the two main functionalities of the toolbox, which is the identification of hotspots and the reporting of profiling results for each one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
More specifically, each selection functionality is described below:
|
|
|
|
- Energy Consumption Estimation Component (Static Analysis): It is part of the Consumption Analysis sub-component. Its functionality is described in D5.6, while D4.5 gives a complete section with details on its design and implementation. It is based on the CLANG compiler, the LLVM-mca, as well as the Scikit learn Python library. Static analysis tool incorporates estimation models and is capable of providing fast results, also giving the developer the opportunity to make Energy Consumption predictions about running an application on different platforms.
|
|
|
|
- Energy indicators monitoring and hotspots identification (Hot-spots): This functionality is part of the Consumption Analysis sub-component and is based on the Valgrind suite as well as Linux Perf. Energy Consumption indicators (see D3.2) are presented by the Toolbox, in order to characterize the application in terms of Energy Consumption and to assist developers on identifying the individual characteristics of the application that consume more Energy. The Energy Hotspots identification is based on Valgrind and CLANG and identifies the blocks of code that may consume more energy. These results are intended to help developers find application source code locations to focus on.
|
|
|
|
- History Analysis: Presents the static analysis Energy and Time estimations for all the project commits that have been analysed using the Toolbox in the past, retrieving the information from the embedded database.
|
|
|
|
- Android Analysis: The Energy Toolbox additional mechanism for supporting Android applications was described in a detailed manner in D6.4. This tool, based on Anandroid, monkeyrunner and Greenscaler profiler, reports Energy indicators such as Memory Usage (bytes), CPU Load (percentage), CPU Frequency (Hertz), Context Switches (count), Test case duration (seconds), System calls (count), Total Energy (Milijoules).
|
|
|
|
- Optimization Suggestions (on Full and on Acceleration): As part of the Estimation & Optimization Sub-component, this analysis proposes refactoring opportunities. The most important functionality is Energy Gains by Acceleration Estimation. Energy hotspots are analysed through dynamic instrumentation and the Acceleration specific indicators are passed to estimation models. Suggestions for cache-blocking optimization are also provided after analysing the cache behaviour in the application loops.
|
|
|
|
|
|
|
|
The following image shows the static Consumption Analysis panel which is a part of the Energy toolbox front-end:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This panel consists of two parts:
|
|
|
|
- Profiling results per function or loop: The energy estimation can be reported at function-level and at loop-level. Developers can configure this selecting by “Granularity”. The energy estimation values for each row in the table are adjusted based on the selected granularity level.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Estimating the energy consumption across whole application for different embedded platforms: There is a drop-down list of the available devices that are already imported in the Energy Toolbox:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In addition, there is a form where the user can set the number of iterations per loop. In the left box the loop id is selected, while in the right box the number of iterations is set. After pressing the “Calculate” button all the energy estimations are re-calculated and the user can proceed in setting the iterations number for another loop.
|
|
|
|
|
|
|
|
Energy indicators monitoring and hotspots identification panel is presented below:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This panel consists of two parts:
|
|
|
|
Profiling results across the whole application: Includes the following profiling information, which correspond to the indicators for energy consumption, as reported in D3.2: “Suitable Indicators for energy consumption”:
|
| ... | ... | @@ -24,10 +52,18 @@ Profiling results per hotspot: Includes the hotspot ID, source file, start and e |
|
|
|
* Ratio of cache misses
|
|
|
|
The hotspots can be identified at two granularity levels: At function-level and at loop-level. Developers can configure this selecting by “Hotspot Granularity”.
|
|
|
|
|
|
|
|
The values of Energy indicators characterize the applications Energy Consumption, helping to further explore the characteristics of the program that consume more energy. In addition, the hotspots identification assists developers to find the places of the application that potentially consume more energy
|
|
|
|
|
|
|
|
The next Figure depicts the values of a subset of the acceletor-specific indicators (i.e. the ones that influence the accelerator decision in higher degree than the others) for each hotspot. The values of these indicators are shown when “Full Analysis” is initially selected. The “Hotspot Granularity” is also applicable in this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The proposed optimizations per hotspot are depicted in the lowest part of the energy toolbox GUI, shown in the following Figure. The first column is the hotspot ID and the second the proposed optimization for each one.
|
|
|
|
|
|
|
|
 |
|
|
\ No newline at end of file |
|
|
|
|
|
|
|
|
|
|
|
The Energy Toolbox also provides the opportunity to present the static analysis estimations for all the project commits that have been analysed using the Toolbox in the past, retrieving the information from the embedded database. An example of the history analysis results is presented in the next picture:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Based on these results, a user could find the estimated energy consumption and execution time for each version of the project under analysis for the use of different platforms. In the presented example the energy is lower for the use of ARM Cortex M0+, while the estimated execution time is higher compared to the execution of the application in the more complex ARM Cortex A-57. There is also an increase in Energy Consumption (about in the middle of the project’s history). A new functionality might be added in these commits, which does not exist after certain versions of the project. |
|
|
\ No newline at end of file |
