MERIC wrapper
HOW IT WILL WORK
1] run of the analyzed application to measure its behavior + HW performance counters
2] construction of the call-path graph
3] load of the measured values for each region of the application + subtraction of the values that belong to nested regions
4a] (after the first run) based on HW counters we estimate optimal system configuration for each region
4b] (every other run) evaluation of the measurements and specification of the following regions' configurations
5] if we don't have optimal configuration for each region, continue to step 1
REQUIRED CHANGES IN MERIC OUTPUT
-
store the graph of regions' call-paths to avoid its construction from the measured data -
add information to the output (infoStore) whether the configuration has changed at the beginning of the region -
instead of storing the data into the files with the same name, each region will have to store its values into file that has name according the configuration that had been applied for it -
remove mericMeasurementCounters, iteration number will be provided by the wrapper (iteration number has been related to the static application configuration, however there will be no more static configuration) export MERIC_ITERATION=$iteration
CONSEQUENCES
- if the exhaustive search will not be used RADAR tools will neither be able to analyze nor visualize the measurements. Analysis will be provided by the wrapper, so it is not such problem, however RADARvisualizer also does not work when some data is missing
- it also means that RADARvisualizer will need new backend to load the data and MERIC configuration file
- on the other hand if user will not use the wrapper (or select exhaustive search), changes in the output should not influence RADAR analysis
- measurement of the static optimum will be optional - if user does not want to compare the savings, than the value is not important
Changes in the output format should be done before any code changes at issue #58.