#ORF09 making Parallelism Available to Rule Developers Presentation

This entry is part 30 of 30 in the series October Rules Fest 2009

Charles Forgy is talking about how to make rule engines parallel. He talked before about doing things inside the rule engine to make things faster.

Why?

  • Processors speeds are hitting a plateau
  • Vendors are creating multi-core machines
  • To tackle bigger problems, rule engines need to adapt

Internal Parallelism

  • That was the first thing to do
  • Complex but possible
  • There are limits (Amdahl’s Law) because this relates to the match and conflict resolution algorithm, so the gain is not going to be as high as we would hope

Goals of Parallel OPSJ

  • Increase the rate of change of working memory
    • Enable each rule to do more
    • Allow rules to execute in parallel
  • In short make parallelism visible to rule developer

“It is easy to make a parallel rule language. It is not easy to make a parallel rule language that is usable”

There are different approaches to this.

  • Allowing a rule to be defined such that all instances of the rules can be fired simultaneously, but this has to be done with care to avoid unwanted consequences with tremendous pressure on the rule developer or alternatively the rule language has to be extend to let the rule engine deal with it

Using multiple knowledge sources:

  • Need to allow communication between the Knowledge Sources
  • Need to allow the Knowledge Source to “Pause” instead of exiting
  • Requires the use of “Probes” (special type of rule) that know about 2 Knowledge Sources

Also, multiple levels of Working memory on:

  • Insert operations
  • Send packet operations
  • Conditions

Using multiple threads in a Single Knowledge Source

  • How to make changes to architecture to help support this
  • We want to avoid changes to shared data, but this is a challenge since in traditional KBS everything is global
  • Every thread needs to have access to 2 levels, once for its main work and the other in very controlled manner

Next step is parallelism over networks

  • Except for shared memory, everything should support a distributed architecture
  • Network latency will obviously be there but might still be advantageous

Java is not as fast a C/C++

  • Modern processors are very complex and Java does not take advantage of this properly so instructions per cycle are very low
  • He wishes someone would re-write the code generators to take advantage of this.

Tags: , ,

Leave a Reply