Presentation given at ODBase 2018 to support the submitted conference paper. It covers the enhancements to the Rete algorithm to provide lazy rule evaluation through rule linking, the solution is implemented and benchmarked in the Drools rule engine.

1. Mark Proctor
Chief Architect - Rules, BPM, Optimisation
Red Hat
Reducing the Cost of the Linear Growth Effect using
Adaptive Rules with Unlinking and Lazy Rule
Evaluation

2. Introduction
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

3. The Problem
• Acharya (Scaling up production system 1994) 3 areas:
• Taming the combinatorial explosion
• Improved memory subsystem performance
• Eliminating linear average growth effect
• Wasted work
The Proposed Solution
• Adaptive Rule Network via rule unlinking
• Network sharing
• Lazy rule evaluation
• Isolated rules
• Set Propagation
• Batching of work
Introduction

4. Background
Rete
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

5. Rete
Classes
Account
long accountNo
int balance
CashFlow
Date date
int amount
AccountPeriod
Date start
Date end

6. Rete
select * from Account acc,
Cashflow cf, AccountPeriod ap
where acc.accountNo == cf.accountNo and
cf.type == CREDIT
cf.date >= ap.start and
cf.date <= ap.end
rule “increase balance for AccountPeriod Credits”
when
ap : AccountPeriod()
acc : Account()
cf : CashFlow( type == CREDIT,
accountNo == acc.accountNo,
date >= ap.start && <= ap.end )
then
acc.balance += cf.amount;
end
acc.balance += cf.amount

7. Rete
select * from Account acc,
Cashflow cf, AccountPeriod ap
where acc.accountNo == cf.accountNo and
cf.type == CREDIT
cf.date >= ap.start and
cf.date <= ap.end
rule “increase balance for AccountPeriod Credits”
when
ap : AccountPeriod()
acc : Account()
cf : CashFlow( type == CREDIT,
accountNo == acc.accountNo,
date >= ap.start && <= ap.end )
then
acc.balance += cf.amount;
end
acc.balance += cf.amount

8. Rete
select * from Account acc,
Cashflow cf, AccountPeriod ap
where acc.accountNo == cf.accountNo and
cf.type == CREDIT
cf.date >= ap.start and
cf.date <= ap.end
rule “increase balance for AccountPeriod Credits”
when
ap : AccountPeriod()
acc : Account()
cf : CashFlow( type == CREDIT,
accountNo == acc.accountNo,
date >= ap.start && <= ap.end )
then
acc.balance += cf.amount;
end
acc.balance += cf.amount

9. Rete
select * from Account acc,
Cashflow cf, AccountPeriod ap
where acc.accountNo == cf.accountNo and
cf.type == CREDIT
cf.date >= ap.start and
cf.date <= ap.end
rule “increase balance for AccountPeriod Credits”
when
ap : AccountPeriod()
acc : Account()
cf : CashFlow( type == CREDIT,
accountNo == acc.accountNo,
date >= ap.start && <= ap.end )
then
acc.balance += cf.amount;
end
acc.balance += cf.amount

10. Rete
select * from Account acc,
Cashflow cf, AccountPeriod ap
where acc.accountNo == cf.accountNo and
cf.type == CREDIT
cf.date >= ap.start and
cf.date <= ap.end
rule “increase balance for AccountPeriod Credits”
when
ap : AccountPeriod()
acc : Account()
cf : CashFlow( type == CREDIT,
accountNo == acc.accountNo,
date >= ap.start && <= ap.end )
then
acc.balance += cf.amount;
end
acc.balance += cf.amount

11. Rete
rule "Increase balance for AccountPeriod Credits"
when
ap : AccountPeriod( )
acnt : Account( )
cf : CashFlow( type == CashFlowType.CREDIT,
accountNo == acnt.accountNo,
date >= ap.start && <= ap.end )
then
modify(acnt) {
balance = acnt.balance + cf.amount;
}
end
rule "Decrease balance for AccountPeriod Debits"
when
ap : AccountPeriod( )
acnt : Account( )
cf : CashFlow( type == CashFlowType.DEBIT,
accountNo == acnt.accountNo,
date >= ap.start && <= ap.end )
then
modify(acnt) {
balance = acnt.balance - cf.amount
}
end
CashFlow
date amount type accountNo
12-Jan-12 100 CREDIT 1
2-Feb-12 200 DEBIT 1
18-May-12 50 CREDIT 1
9-Mar-12 75 CREDIT 1
AccountingPeriod
start end
01-JAN-2012 31-MAR-2012
Account
accountNo balance
1 0
CashFlow
date amount type accountNo
12-Jan-12 100 CREDIT 1
9-Mar-12 75 CREDIT 1
CashFlow
date amount type accountNo
2-Feb-12 200 DEBIT 1
Account
accountNo balance
1 -25

12. Rete
rule "Print balance for AccountPeriod" salience -50
when
ap : AccountPeriod()
acnt : Account( )
then
System.out.println( "Account Number " + acnt.accountNo +
" balance " + acnt.balance );
end
Agenda
1 increase balance
arbitrary2 decrease balance
3 increase balance
4 print balance

13. Rete
Root
Alpha Node
Left Input Adapter Node
Join Node
Terminal Node
Root
Account Period Account Cashflow
type == Credit type == Debit
Credit DebitPrint
LIA
Alpha Network
Beta Network
Shared Network

14. Background
Related Research
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

15. • Treat (Miranker 1987)
• Adaptive Networks
• ’rule-active’ flag.
• Linear time cost
• Rete/UL (Doorenbos 1994)
• left and right unlinking
Related Research
Root
Account Period Account Cashflow
type == Credit type == Debit
Credit DebitPrint
LIA
Alpha Network
Beta Network

16. Solution
Segmentation
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

17. • R1 = A B C
• R2 = A D E
• R3 = A B D E
Segmentation
A
C
R1
B B
C
D
E
A
R1 R2
D
E
C
A
B
R1 R3

18. • R1 = A B C
• R3 = A B D E
• R4 = A B D F G
Segmentation
D
E
C
A
B
R1
R3
F
G
R4

19. • R1 = A not ( B not ( C ) ) D
• R2 = A B C
Segmentation
A
D
R1
Not B
Not
C
R2

20. Solution
Bitmask
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

21. • R1 = A B C
• R2 = A D E
Bitmask
A
C
R1
B
1
2
4 1
B
C
D
E
A
R1 R2
1
1
2
2
1
2
1
2
1

22. • R1 = A B C
• R3 = A B D E
• R4 = A B D F G
Bitmask
D
E
C
A
B
R1
R2
F
G
R3
1
2
4
1
2

23. • R1 = A not ( B not ( C ) ) D
• R2 = A B C
Bitmask
A
D
R1
Not B
Not
C
C
R2
1
2
4

24. Solution
Runtime
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

25. • 3 Levels of Memory
• Beta
• Segment
• Rule
Runtime
Rule Memory
Segment Memory
Node
Memory
Node
Memory
Node
Memory
Segment Memory
Node
Memory
Node
Memory
Node
Memory
Segment Memory
Node
Memory
Node
Memory
Node
Memory
Segment Memory
Node
Memory
Node
Memory
Node
Memory
Rule Memory Rule Memory Rule Memory

26. • Linked rules are scheduled for evaluation
• Lazy rule evaluation
• Split Alpha and Beta network evaluation
• Necessary to ensure all possible rules are scheduled,
before evaluation happens.
• Better batch evaluation
• Set Propagation
• Better batch evaluation
• Eventual support for parallel joins and collection-
oriented match (Tambe 1993)
Runtime A
D
R1
Not B
Not
C
C
R2
1
2
4

27. Benchmark
Implementation
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

28. • Both algorithms share large amounts of code
• discrimination tree, expression evaluations, tuple data structures. Lazy rules adds
the propagation set around exist Tuple and alternative rule evaluation code.
• Parameterised benchmarks
• Segments and fan-out, nodes per segment and number of facts.
• Number of facts was maxed at 32.
• All rules generated with expressions so all join attempts match.
• JMH Harness with suitable warmups and execution times.
• 4 Benchmarks
• Match And Fire All Rules
• Repeat First Rule Fire
• Repeat Last Rule Fire
• Iterate And Fire All Rules
Benchmark

29. Conclusion
Results
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

30. • Match And Fire All Rules.
• Expected similar results, as no wasted
work. However lazy was twice as fast
• and growing.
• Conf 5 is 25.9% to 74.1%
• Repeat First Rule Fire.
• 3.8% to 96.2% for conf 5.
• Can see Rete getting slower as more
• rules added. GC also an impact.
• Repeat Last Rule Fire.
• Same as ^
• Iterate And Fire All Rules.
• 16.7% to 83.3%. Set Propagation larger
impact than expected.
Results
ms/op percentage stack
ms/op
ms/op
ms/op
percentage stack
percentage stack
percentage stack

31. Conclusion
Future work
• Introduction
• Background
• Rete
• Related
Research
• Solution
• Segmentation
• Bitmask
• Runtime
• Benchmark
• Implementation
• Conclusion
• Results
• Future Work

32. • Alpha network unlinking, to have same advantages of
Rete/UL on large fanouts.
• Improved linking heuristics, such as arc consistency
•
Future Work