Hi Ernest,
Thanks for your clarification. The underlying issue is clear to me now than
earlier. My earlier post was more on the lines of a question "Why is this
happening" than a statement "Jess is bad". Am glad it ended up improving
Jess performance.
-Satish.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 12:54 PM
To: Satish boggavarapu
Cc: '[EMAIL PROTECTED]'
Subject: Re: JESS: Jess Vs Clips
Hi all,
Just a quick note to say that I took this email as a personal
challenge and finally sat down and wrote a priority-queue-based agenda
handler for Jess. I now get numbers on this benchmark which are quite
a bit more reasonable:
50 facts: 2 seconds
75 facts: 9
100: 29
125: 1:40
150: (not enough memory)
These times are within a factor of 3 or 4 of CLIPS, a quite believable
C/Java performance comparison number if both CLIPS and Jess are using
the same basic algorithm. Unfortunately Java performance is hobbled
here by the array-bounds checking, and there isn't much I can do to
improve matters.
In any case, as I said before, this isn't a very realistic test --
it's a microbenchmark for conflict resolution. As such, it pointed out
a real flaw in Jess, and I'm happy to say that it's been
rectified. The new agenda management will be in the next release (Jess
60a4, within the next month.) The bad news is that if you've
previously written a Strategy class, that interface has changed
completely. The good news is that the task of writing a conflict
resolution strategy now consists simply of writing a
java.util.Comparator-like class.
Programs with large pending agendas can expect to see a small
performance improvement; Jess' "manners" benchmark score improves by
about 15%.
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]
---------------------------------------------------------------------
