Figure 11.13 A cycle violates the assumption if p does not have a bounded response time.

Response Time In order to use Algorithm A and Algorithm M to compute the maximal number of rule firings and comparisons, PI graph G Pp I must be acyclic. We have proved that these three subclasses of cyclic programs possess the property of execution termination in theorems 3, 4, and 5. Suppose that the PI graph G Pp I contains only n-type cycles. Let r1, r2 G Pp I denote an n-type edge. According to definition 7, the RHS of r1 does not contain an action that produces a WME matching a nonnegated condition element of r2. New WMEs to r2 cannot result from the firings of r1. Hence, the edge r1, r2 should be removed from G Pp I . Since each cycle in G Pp I is an n-type cycle, there is at least one n-type edge in each cycle. This in turns means that at least one edge is removed from each cycle in G Pp I . All of the cycles in G Pp I are thus broken and the resulting graph is acyclic. In theorem 4, we conclude that G Pp I contains only p-type cycles, and for each cycle C G Pp I and C contains a pair of rules, ri and r j , such that ri dis-instantiates r j . This means that every time ri is fired, the firing of r j produces a WME that matches a negated condition element of r j . Then one edge can be removed from each cycle and all of the cycles are thus broken. In theorem 5, we conclude that the execution of p always terminates in a bounded number of recognize–act cycles if, for each cycle C G Pp I , C contains a pair of rules, ri and r j , such that the firing of ri removes a WME matching a nonnegated condition element of r j , and no rule in C can produce a new matching WME of r j . So, we can apply Algorithm A and Algorithm M to any one of these subclasses of programs.

11.3.4 List of Symbols

We summarize the symbols used below:

• G Pp I : a potential instantiation graph of OPS5 program p.

•Nri : the number of matching WMEs of cri .

•dri : the number of matching WMEs of cri that are removed from the working memory as a result of one firing of rule r.

422TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

•cri : the ith condition element of rule r.

•Ir : the maximal number of rule firings of r.

•B: the maximal number of rule firings by OPS5 program p.

•NEri : the number of WMEs produced by the rule ri .

•Nik, j : the number of new matching WMEs of the kth condition element of ri produced as a result of one firing of rule r j .

•NEc : the number of each working memory element.

•Rv, Lv: the maximal numbers of tokens in the R-list and L-list of the node v.

•vx : the number of comparisons conducting in node v.

•Trα: the maximal number of comparisons of class α conducted by rule r, when a token of the class α is processed by the Rete network.

•T α: the maximal number of comparisons made in the Rete network and in one recognize–act cycle when a token of the class α is processed by the whole network.

•nrα: the number of tokens of the class α added or deleted as a result of the firing of rule r.

•Tr : the maximal number of comparisons made by the Rete network as the result of the firing of rule r.

•Tp: the maximal number of comparisons made by the Rete network during the execution.

•Rp: the Rete network.

11.3.5 Experimental Results

In this section we present the results of experiments on OPS5 programs Callin, Manners, and Waltz in Table 11.6. We run these three OPS5 programs on a DEC 5000/240 workstation that supports DEC OPS5 Version 4.0. We also run our analysis tool using these programs. Callin is to compute log2 N . Waltz is a benchmark labeling algorithm and Manners is a benchmark program that assign seats to people around a table. Table 11.6 shows that the actual number of rule firings of Callin using the DEC is greater than that produced by our analysis tool, because there is a rule firing cycle in the Callin program. So, it is not appropriate to use our analysis tool for a cyclic OPS5 program because its result may not be correct. For the Manners program, we

TABLE 11.6 Experimental results using Algorithm A and Algorithm M

invoke three WMEs of the class Guest, one WME of the class Seating, one WME of the class Context, and one WME of the class Count. The actual number of rule firings we observed from DEC is seven. Our analysis tool shows the number of rule firings is nine. For program Waltz, each initial WME consists of one WME of the class Stage and 20 WMEs of the class Line. The actual number of rule firings from these executions is 47, and our tool produces 82. The tightness of the upper bound predicted by algorithm A is shown in the Manners and Waltz experimental results. DEC does not provide a function to generate the number of comparisons. So, we obtain the number of comparisons by manually simulating how it operates in DEC. In the Manners program, the actual number of comparisons is 315, and our tool shows 365. When we run this program using the actual number of initial WMEs of each class, the results for both cases are very close. In the Waltz program, the number of actual comparisons is 273,367, and our tool shows 293 million. This is because we assume the maximal possible number of initial WMEs of each class. Though the difference between them is quite large, we think it is acceptable as an upper bound on the number of comparisons considering that our tool employs pre-run-time static analysis.

11.3.6 Removing Cycles with the Help of the Programmer

We have implemented an analysis tool to predict the upper bounds on the numbers of rule firings for OPS5 programs with acyclic potential instantiation graphs. However, a real-world OPS5 program usually contains cycles of potential instantiations. Some types of cycles do not change the property of termination, while others do. Our tool can automatically remove only a certain type of cycles at this time.

The response time of programs with cyclic potential rule firing patterns usually depends on the value of run-time data that cannot be known in advance. For example, consider the following rule.

(p make new data2 (upperlimit ↑value n )

(data1 ↑xvalue{x1 n})

−→

(modify 2 ↑xvalue (compute x + 1)) (make data2 ↑yvalue x1 ))

The value of the attribute ↑value can only be known at run-time. There is no way to know in advance how many times this rule will be fired, although it is clear that this rule will always terminate.

It is not realistic to try to develop an algorithm to predict the response time upper bounds of programs with cyclic potential rule firing patterns. The most we can do at this time is to determine the property of termination for some of the programs with cyclic potential rule firing patterns.

The property of termination of a given program depends on whether all of its potential rule firing cycles terminate. Hence, it is necessary to check each cycle to see if it always terminates. Due to the lack of run-time information, which is very cru-

424 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

cial in determining the satisfiability of condition elements, a conservative approach has to be taken in static analysis to determine whether a condition element can be satisfied by a working memory element whose value/content cannot be known in advance. The potential instantiation graph produced as a result of the static analysis usually contains a lot of edges that are nonexistent. This in turn means that a lot of cycles found in the potential instantiation graph are nonexistent. With the help of the programmer, a large number of these nonexistent edges/cycles can be detected and removed from the potential instantiation graph.

It is usually the case that a special purpose working memory element is used to control the progress of program execution. Frequently, an OPS5 production system contains a working memory element of the form

(stage ↑value),

where the attribute ↑value contains the value of “stage1”, “stage2,” . . ., or “stage n.” Meanwhile, each of the rules in the program contains a condition element thatz matches this special working memory element. Rules to be fired in different phases request different values of the attribute ↑value of the above working memory element.

Our tool does not know that the above special working memory element is used to control the flow of the execution and, as a result of this function, eliminate a lot of potential cycles. The analysis tool cannot assume that a certain working memory element and certain condition elements of rules provide special function and should be treated differently. All of the working memory elements and all of the condition elements must be treated equally by the analysis tool. On the other hand, the programmer can easily recognize that this particular working memory element is used to control the progress of execution and determine that the existence of some potential rule firing cycles is actually not possible.

For example, when the entire Waltz program is analyzed by our tool, many potential cycles of rule firings are found to be nonexistent, as follows. This program uses the aforementioned special working memory element to control the flow of program execution. Rules are numbered from 0 to 32. Figure 11.14 shows the matrix representation of the potential instantiation graph, where “p” stands for the existence of a p-type edge, “n” stands for the existence of an n-type edge, and “-” stands for the existence of no edge at all. One p-type cycle that was detected is r1, r6 , r6, r3 , and r3, r6 (see Figure 11.14). This type of cycle cannot be removed by our analysis tool. A programmer can determine if some of these edges can be removed.

It is clear from this graph that many potential rule firing cycles occur during the execution. Many of these potential cycles can be removed by the programmer. Our tool finds all of these cycles and prompts a message to the programmer for each detected potential cycle. The programmer then checks each potential cycle and determines whether a special purpose working memory element breaks it.

For instance, the graph shows that there is a potential cycle involving only rule 6 and rule 7, which, respectively, are

426 TIMING ANALYSIS OF PREDICATE-LOGIC RULE-BASED SYSTEMS

(p initial boundary junction L ; rule #6 (stage ↑value find initial boundary)

(junction ↑type L ↑base point base point ↑p1 p1 ↑p2 p2 ) (edge ↑p1 base point ↑p2 p )

(edge ↑p1 base point ↑p2 p2 )

– (junction ↑base point > base point )

−→

(modify 3 ↑label B)

(modify 4 ↑label B)

(modify 1 ↑value find second boundary)) and

(p initial boundary junction arrow ; rule #7 (stage ↑value find initial boundary)

(junction ↑type arrow ↑base point bp ↑p1 p1 ↑p2 p2 ↑p3 p3 ) (edge ↑p1 bp ↑p2 p1 )

(edge ↑p1 bp ↑p2 p2 ) (edge ↑p1 bp ↑p2 p3 )

– (junction ↑base point > bp )

−→

(modify 3 ↑label B)

(modify 4 ↑label P)

(modify 5 ↑label B)

(modify 1 ↑value find second boundary))

Whenever either one of these two rules is fired, the execution enters the next phase since the attribute ↑value of the flow-controlling working memory element is set to the value that initiates the next phase of the execution. Hence, it is not possible for these two rules to be cyclically fired. The dependency analysis performed by our tool cannot detect this fact, since the tool cannot assume the existence of a flowcontrolling working memory element.

The programmer can help the analysis tool recognize this fact by rewriting (but not changing the semantic of) these two rules. After a closer look at these two rules, coupled with the understanding of the Waltz algorithm, it is not difficult for the programmer to realize that some condition elements of these rules are reasonably simplified due to the use of the flow-controlling working memory element. For example, the working memory elements matching the third condition element of rule 6 are actually of the form

(edge ↑p1 base point ↑p2 p1 ↑label nil ↑plotted nil).

Because of the use of the flow-controlling working memory element, the condition element considered does not explicitly specify the required values for the last two attributes. Any working memory element of the class edge with the value of ↑label being B or P will not be used to produce an instantiation of rule 6, since the program execution enters the next phase after the attribute ↑label of this working memory

element is set to B or P as a result of the firing of either rule 6 or rule 7. So, the rewritten rule 6 and rule 7 are as follows:

(p initial boundary junction L ; rule 6 (stage ↑value find initial boundary)

(junction ↑type L ↑base point base point ↑p1 p1 ↑p2 p2 ) (edge ↑p1 base point ↑p2 p1 ↑label nil ↑ plotted nil) (edge ↑p1 base point ↑p2 p2 HERE ↑label nil ↑plotted nil)

– (junction ↑base point > base point )

−→

(modify 3 ↑label B)

(modify 4 ↑label B)

(modify 1 ↑value find second boundary)) and

(p initial boundary junction arrow ; rule #7 (stage ↑value find initial boundary)

(junction ↑type arrow ↑base point bp ↑p1 p1 ↑p2 p2 ↑p3 p3 ) (edge ↑p1 b ↑p2 p1 ↑label nil ↑plotted nil)

(edge ↑p1 bp ↑p2 p2 ↑label nil ↑plotted nil) (edge ↑p1 bp ↑p2 p3 ↑label nil ↑plotted nil)

– (junction ↑base point > bp )

−→

(modify 3 ↑label B)

(modify 4 ↑label P)

(modify 5 ↑label B)

(modify 1 ↑value find second boundary))

We check each cycle and, if possible, rewrite rules by explicitly specifying the required values of attributes for each condition element. Figure 11.15 shows the new potential instantiation graph obtained when the resulting program is analyzed. There are still many cycles, which need to be analyzed by a more sophisticated method, but the number of cycles has been remarkably reduced in comparison with the number of cycles in the old PI graph in Figure 11.14.

The programmer can further help by exploiting his/her understanding of the semantics of program flow. The programmer can determine that some cycles are terminating. For example, a cycle that consumes a certain class of working memory elements will eventually terminate if only a limited number of working memory elements of that class exist during the execution.

Example 20. The following is the output produced by our analysis tool when analyzing the benchmark program called Manners, which assigns seats to people around a table. Note that some cycles are broken as a result of removing some edges by the programmer with the understanding of the semantics of program flow. The upper bound obtained is very loose because it suffers from the conservative approach taken.

**************** Analysis results **************

***PI graph

After removing n-type cycles...

***PI graph