# Improving Symbolic System-Level Synthesis by Solver Coordination and Domain-Specific Heuristics
## 8 Experimental Results
### Experimental Results
#### 8.3.2 Results of Coordinated Approach  
Table 2 contains the number of solved runs for the different instances in the instance sets for the _coordinated_ approach (columns \"coord\"). First of all, we compare the entries of the _classical_ and the _coordinated_ approach where none of the instances of an instance set is solved (\"0/5\" column). We see that up to the 5 \(\times\) 5-70 instances the _coordinated_ approach considerably more often is able to find at least one feasible synthesis out of five runs per instance than the _classical_ approach. Table 2 also indicates the limitations of the coordinated approach. Starting with the 5 \(\times\) 5-70 instance set, considerably more instance cannot be synthesized within five independent runs of an instance. Ultimately, for the hardest instances of 6 \(\times\) 6-70, only one run for one instance was solved. Despite this, by looking at the obtained results as a whole, the _coordinated_ approach is still a considerable improvement regarding the applicability towards larger problem instances compared to the _classical_ approach. To one essential part, the increase in applicability of the _coordinated_ approach is due to the load balancing objective in the coordinated approach as we conjecture that deciding schedulability of not fully utilized tiles can be considered as an easier task. Hence, in the background theory, the tile scheduling stage of the hierarchical scheduling scheme consumes significantly less time than in the _classical_ approach. Furthermore, also the other optimization statements contribute to the improvement of the coordinated approach as these statements allow to decide scheduling faster within the independent application scheduling stage in the hierarchical scheduling scheme. However, adding the necessary auxiliary variables and the optimization of the _coordinated_ approach to the answer set solver comes with a non-negligible cost in terms of additional variables and constraints. Looking at our instances, the additional number of variables, which are reported by the answer set solver, increased between 9% for the smaller instance up to 40% for the largest instances. Similarly, the number of additional constraints increased between 22% for the smallest instances, respectively, 35% for the largest instances. As one numerical example, for the 6 \(\times\) 6-70 instances and the _classical_ approach, the average number of variables and constraints and the standart deviation was 821,999 \(\pm\) 16,971 variables and 3,848,766 \(\pm\) 303,098 constraints. In contrast, for the _coordinated_ approach these values increase on average to 1,154,760 \(\pm\) 35,410 variables and 5,198,396 \(\pm\) 326,980 constraints. Figure 6: Average runtime distribution between answer set solver (blue) and background theory solver (red) for the timeout runs in the _classical_ approach. More than 90% of the total synthesis time is spent on average within the background theory until the timeout. The vertical error bars show the standard deviation. Often, having more variables and constraints in the answer set solver can increase the time to derive a solution of the binding and routing sub-problem. Additionally, once an initial solution is found, the answer set solver spends up to 10s to optimize this solution (or prove that the found initial one is the optimal solution). While for all the 3 \(\times\) 3 mesh grid instances in the _classical_ approach (note that more detailed data of the solved instances for the _classical_ approach is not shown for the sake of brevity.) the total average time spend in the answer set solver in successful runs is less then 1s, for the same instances it is around 20 s in the _coordinated_ approach. Figure 7 summarizes the average total times spent in the respective parts of the answer set solver and the background theory solver within the _coordinated_ approach for the runs that finished successfully (note that the figure also contains the runtime for the enhancements with the DSH).