VMS/0__Writings/kshalle

changeset 75:f0347dbf1702

perf-tuning small mod to concreteness of UCC
author Sean Halle <seanhalle@yahoo.com>
date Thu, 09 Aug 2012 16:46:09 -0700
parents a65dcc907150
children 0c973449ccdd
files 0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex
diffstat 1 files changed, 3 insertions(+), 3 deletions(-) [+]
line diff
     1.1 --- a/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex	Thu Aug 09 16:15:33 2012 -0700
     1.2 +++ b/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex	Thu Aug 09 16:46:09 2012 -0700
     1.3 @@ -330,7 +330,7 @@
     1.4    \label{fig:UCC_example}
     1.5  \end{figure}
     1.6  
     1.7 -    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.
     1.8 +    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.
     1.9  
    1.10  
    1.11  \begin{figure}[ht]
    1.12 @@ -340,9 +340,9 @@
    1.13    \label{fig:UCC_Concreteness}
    1.14  \end{figure}
    1.15  
    1.16 -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. 
    1.17 +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. 
    1.18  
    1.19 -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).
    1.20 +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).
    1.21  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.
    1.22   
    1.23  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.