5

I was really happy to see a rules engine in Node and also was looking at Drools in the Java world and while reading the documentation (specifically: http://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html_single/index.html#PHREAK)found that Drools 6.0 has evolved and now uses the PHREAK method for rules matching. The specific paragraph that is of interest is:

Each successful join attempt in RETE produces a tuple (or token, or partial match) that will be propagated to the child nodes. For this reason it is characterised as a tuple oriented algorithm. For each child node that it reaches it will attempt to join with the other side of the node, again each successful join attempt will be propagated straight away. This creates a descent recursion effect. Thrashing the network of nodes as it ripples up and down, left and right from the point of entry into the beta network to all the reachable leaf nodes.

For complex rules and rules over a certain limit, the above quote says that RETE based method trashes the memory quite a lot and so it was evolved into PHREAK.

Since nools is based on the Rete algorithm, is the above valid? Are there any optimizations done similar to PHREAK? Any comparisons done w.r.t to Drools?

Stephan Muller
  • 27,018
  • 16
  • 85
  • 126
user1749672
  • 116
  • 1
  • 8

1 Answers1

9

The network thrashing is only an issue when you want to try and apply concurrency and parallelism, which requires locking in areas. As NodeJS is single threaded, that won't be an issue. We haven't yet attempted to solve this area in Drools yet either - but the Phreak work was preparation with this in mind, learning from the issues we found from our Rete implementation. On a separate note Rete has used partition algorithms in the past for parallelism, and this work is in the same area for the problem it's trying to solve.

For single threaded machines lazy rule evaluation is much more interesting. However as the document notes a single rule of joins will not differ in performance between Phreak and Rete. As you add lots of rules, the lazy nature avoids potential work, thus saving over-all cpu cycles. The algorithm is also more forgiving for a larger number of badly written rules, and should degrade less in performance. For instance it doesn't need the traditional Rete root "Context" object that is used to drive rule selection and short-circuit wasteful matching - this would be seen as anti-pattern in Phreak and may actually slow it down, as you blow away matches it might use again in the future. http://www.dzone.com/links/rip_rete_time_to_get_phreaky.html

Also the collection oriented propagation is relevant when multiple subnetworks are used in rules, such as with multiple accumulates. http://blog.athico.com/2014/02/drools-6-performance-with-phreak.html

I also did a follow up on the backward chaining and stack evaluation infrastructure: http://blog.athico.com/2014/01/drools-phreak-stack-based-evaluations.html

Mark (Creator of Phreak)

Mark Proctor
  • 691
  • 4
  • 5
  • Mark, thanks for your input. I will dive into the references you provided. In terms of performance, can you point out the delta between RETE and PHREAK implementations? – user1749672 Oct 21 '14 at 04:31
  • There is no single delta, it'a very hard to give direct comparisons. Because it's not that the lazy algorithm is faster, it's just doing less - which in many cases results in faster application execution. The first provides a link for one such delta on the use of accumulates and subnetworks, that shows the algorithm at it's best by orders of magnitudes. Other application applications may only see a 10% gain, and a few others a 10% slowdown. Although I hope in the case of the later, it's just a matter of profiling and tuning to address this. – Mark Proctor Oct 21 '14 at 17:43
  • Thanks Mark. Appreciate your insights and response. – user1749672 Oct 23 '14 at 08:39