# HG changeset patch # User Sean Halle # Date 1344555969 25200 # Node ID f0347dbf170287c3d6eef45cb4047966326604f1 # Parent a65dcc9071506c82b196fb5c5f24eac8381bb705 perf-tuning small mod to concreteness of UCC diff -r a65dcc907150 -r f0347dbf1702 0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex --- a/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex Thu Aug 09 16:15:33 2012 -0700 +++ b/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex Thu Aug 09 16:46:09 2012 -0700 @@ -330,7 +330,7 @@ \label{fig:UCC_example} \end{figure} - We call a fully specified UCC a \emph{concrete} UCC. Every run of an application eventually winds up defining a concrete UCC, such as produced for the performance tuning seen in Fig \ref{fig:UCC_example}. But the amount of UCC made concrete by the application alone falls into a two-dimensional grid. One dimension covers the units, the other the constraints. + We call a fully specified UCC a \emph{concrete} UCC. Every run of an application eventually winds up defining a concrete UCC, such as produced for the performance tuning, seen in Fig \ref{fig:UCC_example}. In it, every unit scheduled in the SCG appears, along with the application-defined constraints on scheduling them. For this application, parameters determine how the work is divided, and so determine the units. Hence, the application alone does not specify the concrete UCC, because the parameter values must be known before the units can be determined. In general, the amount of UCC made concrete by the application alone falls into a two-dimensional grid. One dimension covers the units, the other the constraints. \begin{figure}[ht] @@ -340,9 +340,9 @@ \label{fig:UCC_Concreteness} \end{figure} -Figure \ref{fig:UCC_Concreteness} shows the two axes and the four sets of information on each, which act as the inputs that determine the units and constraints. The position a UCC lands on the grid indicates how far it is from being fully concrete. The horizontal indicates what inputs are still needed to determine the units, and vertical the constraints. 0 indicates that the units (constraints) are fully determined by the application code alone; 1 means parameter values also must be known; 2 means input data values also play a role, and 3 means the units (constraints) can only become known after runtime scheduling decisions have been made. +Figure \ref{fig:UCC_Concreteness} shows the two axes and the four sets of additional information required to determine the units and constraints in the final concrete UCC. The position an application-derived UCC lands on the grid indicates how far it is from being fully concrete. The horizontal indicates what inputs are still needed to determine the units, and vertical the constraints. 0 indicates that the units (constraints) are fully determined by the application code alone; 1 means parameter values also must be known; 2 means input data values also play a role, and 3 means the units (constraints) can only become known after runtime scheduling decisions have been made. -The closer the application-derived UCC is to the origin, the less additional information it needs to become concrete. The UCC labeled A in the figure is fully concrete just from the source code alone (representing for example, matrix multiply with fixed size matrices). The UCC labeled B requires the input data and parameters to be specified before its units are concrete, but just parameters to make its constraints fully concrete (as per ray-tracing, with bounce depth specified as a parameter). The UCC labeled C only has variability in its constraints, which require input data (for example, H.264 motion vectors). +The closer the application-derived UCC is to the origin, the less additional information is needed to obtain a concrete UCC descendant of it. The UCC labeled A in the figure is fully concrete just from the source code alone (representing for example, matrix multiply with fixed size matrices and fixed division). The UCC labeled B requires the input data and parameters to be specified before its units are concrete, but just parameters to make its constraints fully concrete (as per ray-tracing, with bounce depth specified as a parameter). The UCC labeled C only has variability in its constraints, which require input data (for example, H.264 motion vectors). But even the least concrete UCC, out at the end of the diagonal (D in the figure), becomes concrete during a run of the application. Notice, though, that even a fully concrete UCC still has degrees of freedom, in which units to run on which hardware and in the order of execution. These decisions fix interactions within the hardware, to yield the communication patterns and consequent performance seen during the run.