|
|
The front-end of the Energy Toolbox is actually part of the overall SDK4ED Dashboard. The front-end of the the Energy Toolbox communicates with the back-end, allowing the easy invocation of the main functionalities (i.e., web services) that the toolbox provides, and the visualization of the produced results.
|
|
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.
|
|
|
|
|
|
|
|
|
Figure 1 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.
|
|
|
|
|
|
|
|
Figure 2 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.
|
|
|
|
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”:
|
|
|
|
* CPU cycles: The number of CPU cycles for the whole application execution
|
|
|
|
* Data races: Number of data races identified during execution
|
|
|
|
* Memory accesses: Number of memory accesses occurring for the whole execution
|
|
|
|
* Ratio of branch misses: Indicating branch mispredictions during execution
|
|
|
|
* Cache miss rate: The ratio of cache misses during execution
|
|
|
|
* D cache misses: The ration of data cache misses
|
|
|
|
Profiling results per hotspot: Includes the hotspot ID, source file, start and end line of the specific hotspot, as well as the following indicators:
|
|
|
|
* CPU cycles
|
|
|
|
* 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 indicator values for each hotspot are adjusted based on the granularity level.
|
|
|
|
The values of the indicators are obtained by dynamic analysis, by using the flow described in 3.1.1. However, they can also be obtained on an actual embedded platform, if available.
|
|
|
|
|
|
|
|
Figure 3 shows 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 Figure 4. The first column is the hotspot ID and the second the proposed optimization for each one. |
|
|
|
\ No newline at end of file |
