## 4 Computation and Communication Performance Modeling Approaches
### Computation Modeling Approach
#### 4.1.2 Data Dependency Consideration  
Considering data dependency can improve the accuracy of execution time prediction, because software often comes with different execution paths triggered by the input data processed by the software. Each path may have a different execution time. In Figure 3 three abstraction levels of data dependency handling are shown. Beginning with a fine granular abstraction at the top of the figure, and ending with a sound model at the bottom. For each abstraction level, the data dependent execution time modeling process is shown for an example actor. In magenta, the actors executed on the target platform are shown. Brown color is used to highlight data dependent parts of the software. The execution time observed during the execution of the actor on the target platform is shown in green. The blue part shows how the data dependent execution time model is used inside the simulation. Figure 3 shows the process from left to right to create a data dependent execution time model for an actor. This is a manual, non-automated process that can be applied to any algorithm being executed on any hardware platform and improves our concept of observation based characterization of the computation time of an actor. It does not require static analysis tools that are restricted to specific platforms and does not come with restrictions to the algorithm like bounded loops. The more abstract the model becomes, the less knowledge about the algorithm and the hardware platform is required. The _first approach_ shown in Figure 3 (Few Paths) considers all possible individual execution paths of an actor. In the example, the source code of the _ABS_ actor of the _Sobel-Filter_ use-case gets analyzed. For each of the two input tokens, there is a branch with the sign of the input value as condition. This leads to four different execution paths, depending on the sign of the input tokens \(X\) and \(Y\). With this knowledge, a set of stimuli-data can be generated and used to characterize the execution time of each path. Then, knowing the exact execution time for each path, these paths can be modeled in detail inside the simulation. This first approach provides an accurate execution time model but comes with a lot of effort, especially for actors with many execution paths. It does not scale for real applications. In some cases, it is not even possible to do this on source level. For example simple multiplications can be replaced by loops during compilation, when the target platform does not provide a hardware multiplier. The _second approach_ shown in Figure 3 (Intermediate) considers different scenarios for the execution of an actor. The _IDCT_ actor of the _JPEG-Decoder_ use-case is used to demonstrate this approach. This actor implements an Inverse Discrete Cosine Transformation that needs to be applied to all three color channels (\(Y\), \(C_{r}\), \(C_{b}\)) of an JPEG image. The JPEG standard applies different compression strength to these three color channels. Therefore, the characteristics of the three color channels are very different, while the data of the color channels for each MCU (Minimum coded Unit--\(8\times 8\) pixels) have similar characteristics. This knowledge about the algorithm is used to split the execution time model for the _IDCT_ actor into three individual execution time models (\(IDCT_{Y}\), \(IDCT_{C_{r}}\), \(IDCT_{C_{b}}\))--one for each scenario. The same strategy was applied to the _IQ_ actor that performs an Inverse Quantization, a matrix multiplication that becomes data dependent on platforms without hardware  
Figure 3: Modeling process with explicit execution path identification shown at Sobel-Filter example actor _GetPixel_ (**top**), using Kernel Density Estimation shown at JPEG-Decoder example actor _GetMCU_ (**bottom**) and a combination of both for actor _IDCT_ (**middle**). multiplier. The different amount of zeros inside the different quantization tables for each color channel has a huge impact on the execution times.