LA CREATIVIDAD

An important class of graphs, particularly for modelling circuits, are series- parallel graphs [BJG08]. Series-parallel graphs are defined as the class of graphs that reduce to a single edge between two nodes under the following transforma- tions:

1. Replace two parallel edges with a single edge with the same source and target.

2. Replace a directed path of two edges connecting three nodes where the middle node has degree 2, with a single edge connecting the endpoints in the same direction.

We consider directed integer-labelled series-parallel graphs. The definition is directly translated to a GP 2 program using the rules in Figure 5.20 [Plu12].

The program executes the two reduction rules par and seq on the host graph for as long as possible. If the resulting graph is a single non-looping edge, then the host graph is by definition series-parallel. After the reduction, the test concludes with the removal of a non-looping edge with deleteBase and checking that the current graph is empty. The result is encoded, as in the acyclic test, in an isolated root node with the label “yes” or the label “no”. Again, there are two versions of the program to control the presence of graph backtracking mechanisms at runtime.

No Backtracking Graph Copying Graph Recording

Graph Size Runtime Max Runtime Max Runtime Max

10 2 0.037 2 0.043 2 0.056

102 2 0.038 2 0.05 2 0.57

103 18 0.126 20 0.324 21 0.227

104 836 1.699 861 3.312 847 3.302

105 94,412 - 97,594 - 96,276 -

Table 5.5.: Experimental results of three versions of the series-parallel checking program. Graph size is given in number of edges. Runtime is given in milliseconds. Heap use is given in megabytes

101 ₁₀2 ₁₀3 ₁₀4

0 1 2 3

Graph Size (# edges)

Maxim

um

Heap

Usage

(MB)

Series Parallel Checking No Backtracking

Graph Copying Graph Recording

Figure 5.21.: Plot of the memory use of the series-parallel checking programs.

1 Main = {par, seq}!; deleteBase; if nonEmpty then no else yes 2 Main = if ({par, seq}!; deleteBase; nonEmpty) then no else yes

The host graphs used to test this program are machine-generated3 series- parallel graphs, weighted so that the number of parallel edges and the number of “sequential edges” are approximately equal. All nodes and edges are labelled 1. On these host graphs, par performs one host graph modification: removing an edge, while seq performs four: two edge removals, a node removal, and an edge addition. Hence the average number of recorded graph changes per loop iteration is 2.5.

The results can be seen in Table 5.5 and Figure 5.21. Valgrind did not terminate in a reasonable time for the largest host graph. Like the acyclicity testing pro- gram, there is little difference in runtime between the three executions. However, the heap usage evens out for the two programs that perform graph backtracking. The greater number of graph changes per loop iteration requires a greater number of changes to be placed on the stack, hence more memory consumption. To take this a step further, we artificially added more graph changes to the reduction step as shown in Figure 5.22:

3

par(a,b,x,y:int) x 1 y 2 b a ⇒ _x+1 1 y+1 2 a+1 seq(a,b,x,y,z:int) x 1 y 2 a z 3 b ⇒ _x+1 1 z+1 3 a+1 deleteBase(a,x,y:int) x 1 y 2 a ⇒

_∅

Figure 5.22.: Modified rules for series-parallel testing

In the modified program, par performs three relabelling operations in addition to the edge deletion and seq performs two relabelling operations in addition to the node deletion, two edge deletions, and edge addition. This averages out to 5 graph modifications per loop iteration. We ran the modified program on the same host graphs as in the previous experiment. The results in Figure 5.6 and Figure 5.23 show that the memory used by graph recording grows more rapidly than the memory used by graph copying.

5.8.5. Analysis

According to our experiments, the overhead introduced by both forms of graph backtracking has a negligible impact on runtime performance. This falsifies the hypothesis: an increase in the number of recorded graph changes does not de- crease runtime performance. Therefore, for the purpose of optimising the speed of executing graph programs, there is no need to pick and choose one graph recording method over the other depending on the context of the program. How- ever, for space efficiency, the results show that the difference in memory usage is dependent on the program structure and the complexity of the rules. Specifi- cally, for reduction programs in which a large amount of computation needs to be recorded and reversed, either implicitly (by copying the host graph) or explicitly (by storing a representation of the computation), the complexity of the reduction step has a large impact on the relative memory use.

The optimal solution would be to extend the current static analysis to heuris- tically select the graph backtracking mechanism that is estimated to use the least memory with respect to the program structure. This would be a complex exten- sion to the codebase: one would need to design, implement and test a heuristic function based at a minimum on the counts of the changes made by each rule in a critical subprogram. We chose not to take this route since the development time and effort was not worth the small and perhaps insignificant reduction in memory use for a subset of graph program-host graph pairs. Instead, we chose to use graph recording as the sole mechanism for graph backtracking at runtime. The program patterns that strongly favour graph recording, such as those per- forming graph backtracking for a small (and constant) number of graph changes

No Backtracking Graph Copying Graph Recording

Graph Size Runtime Max Runtime Max Runtime Max

10 2 0.037 2 0.056 2 0.043

102 2 0.038 2 0.57 2 0.63

103 20 0.126 19 0.227 20 0.521

104 859 1.699 862 3.302 853 4.885

105 98,789 - 96,230 - 97,608 -

Table 5.6.: Experimental results of three versions of the modified series-parallel program. Graph size is given in number of nodes. Runtime is given in milliseconds. Heap use is given in megabytes.

101 ₁₀2 ₁₀3 ₁₀4 0 1 2 3 4 5

Graph Size (# edges)

Maxim

um

Heap

Usage

(MB)

Series Parallel Checking No Backtracking

Graph Copying Graph Recording

Figure 5.23.: Plot of the memory use of the modified series-parallel checking pro- grams.

and those with nested critical subprograms, are more frequent than critical sub- programs that perform a large number of graph changes with respect to the size of the host graph.