Hi,
Ouch. The folks on this have a remarkable talent for finding weak
spots in Jess.
First of all, modify your program thusly:
(deffunction assert-facts1 (?n)
(printout t "asserting " ?n " facts" crlf )
(while (> ?n 0) (assert (x ?n) (y ?n) (z ?n)) (run) (bind ?n (- ?n 1)))
(printout t "asserting facts Done" crlf))
(defrule foo1 (x ?x) (y ?y) (z ?z) => )
(assert-facts1 50)
The only real change is that I inserted "(run)" into the
fact-inserting loop. On my machine the time for 50 facts drops to 8
seconds, which is within a believeable Java vs. C performance ratio of
3 or 4. The scaling is stil not great for larger numbers, though --
as you noted, this is a bad rule, and it's not the sort of rule that
Jess does well with. Jess performs the best with varied, realistic
systems.
Anyway, the reason that adding (run) makes it go so much faster is
that the Strategy interface isn't very well designed. In your original
program, there were 125,000 activations on the agenda at once --
again, something unlikely to happen in practice! -- and the design of
the Strategy interface is such that adding new activations becomes
very slow when the agenda is large.
The agenda is just an array, and insertions at one end become very
slow when the array is large (switch the strategy to breadth, from the
default depth, and you'll see your program also gets faster, although
not as much. This is because breadth inserts new activations after old
ones, while depth puts them before old ones. The new ones gets stcuck
on the "fast end" of the array.)
Somewhere on my to-do list is converting the agenda-management
to use a priority queue, which won't have this performance problem.
I think Satish boggavarapu wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> Hi,
>
> I want to throw this for discussion. I wrote a bad rule and tried to assert
> facts which generate huge number of matches. I assumed the performance would
> be similar or atleast jess would outperform clips for large number of facts.
> So i used the following deffunction to assert the facts and the defrule to
> get them in to rete. (The benchmark here is only for asserting)
>
> (deffunction assert-facts1 (?n)
> (printout t "asserting " ?n " facts" crlf )
> (while (> ?n 0) (assert (x ?n) (y ?n) (z ?n)) (bind ?n (- ?n 1)))
> (printout t "asserting facts Done" crlf)
> )
>
> (defrule foo1 (x ?x) (y ?y) (z ?z) => (printout t "I am done"))
>
> Its done on a dual processor linux machine with 256MB RAM. Quite
> surprisingly the performance difference is large.
>
> N=50, CLIPS = 2-3 secs, Jess = 140 secs
> N=100, CLIPS = 6 secs, Jess = 17+ mins (almost million+ matches generated
> here with N=100)
>
> When N=150 CLIPS returned in 30 secs.
>
> Does it mean that N=150 still small N even if its generating huge number of
> matches and as we know assertion is a computational intensive task?
>
> retracting all those facts or even a reset is taking considerably more time
> than asserting.
>
> Like to hear experts opinions/views on this.
>
> Thanks in Advance
> Satish.
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
