PERIXML Autotuning
From PERI
Contents |
Introduction
This page documents requirements gathered from the PERI autotuning efforts. Autotuning can occur at different code granularities, so we consider common requirements, as well as requirements applying only for certain types of tuning in different sections below. The pervasive requirement is automation, which is only partly supported by existing tools.
Before analysis and tuning can begin
Prior to modeling or tuning of any kind, data about the application and architecture must be gathered and stored. This includes different kind of timings, hardware counters when available, machine configuration information, application deployment information, and application-specific parameters (metadata) that may influence performance. From the autotuning perspective, support for the following is needed:
- More automation of the data gathering process. There are various tools that gather performance data and store it in various formats. The same or separate tools gather partial hardware and application data. The gathering of application-specific metadata is completely manual in most cases.
- Performance data. Hardware counters are no longer accessible in a standard way on many current machines. While tools such as TAU instrument code and gather counter data automatically, the user is still responsible for knowing the correct counter names and figuring out what groups of counters can be used together. Minimizing the experiments needed to gather data for modeling is far from trivial and completely manual at present.
- Provenance data. There are two main types -- hardware data, which does not change frequently (only when a machine is upgraded) and software data, which describes both the environment and the application, i.e., O/S version, compilation details, etc.
- Application-specific metadata. For algorithm-level tuning, we must be able to capture the values of parameters that potentially impact performance (we refer to them as application metadata). The differences between this type of metadata and the metadata that is currently defined in the PERI XML representation are:
- the data is application-specific, so cannot be defined a priori by the PERI tool developers
- the data is dynamic, i.e., in iterative algorithms, one may need to store the value of a parameter for each iteration
- the date must be associated with performance data; since this metadata is dynamic, we need to be able to associate each specific value with the performance information for the corresponding computation phase.
Analysis
Once sufficient data is available in a database, different analysis tools and techniques can be applied to it. Some autotuning tools have tightly integrated analysis, while others rely on stand-alone analysis tools or human analysis. In either case, ideally it shouuld be possible to:
- access data (performance, provenance, application-specific metadata) in a uniform way, i.e., not having to write different code to interface with N different formats produced by N different tools. This can be accomplished through either a standard data format or through standard APIs for accessing different data formats (or both).
- store analysis results in a well-defined format that can be retrieved and interpreted later by humans, tuning tools, application configuration tools, etc. Analysis results should be compact compared with the data they were derived and should be available in flat file formats (in addition to the ability to store them in traditional databases).
Loop-level tuning
For loop-level tuning, detailed performance data (hardware counters), as well as provenance data are essential.
Algorithm-level tuning
For algorithm-level tuning, even basic performance data (e.g., wall-clock time) is normally sufficient, but there must be a way to easily specify and then automatically record application metadata and also automatically associate it with the corresponding performance data.
