I checked with Jon, and he has been tweaking the Jess program and has
now timings of 10-30 times slower. I must admit that JCHR does not
perform that well on this particular benchmark, since my join orderer is
not that good yet. Also, I must admit 10-30 is better then I was
anticipating, so I might have to some more tests later (but, as I said
before, the RETE-Leaps thing doesn't matter that much here, so that is
probably an important factor).
Obvious things, well:
- we do not use RETE, but something that is closer to Leaps (i.e. only
make those joins you need). There is the claim Leaps is asymptotically
better then RETE, but I must admit I have never seen it proved.
- we compile to host-language code (for JCHR this is Java), whereas (I
think) most rule engines are more interpreters. The generated code will
be quite specialized towards the particular rule it is part of, the join
that has to be made, etc.
- we use high performance hash indexes to do the lookups, but I guess
everyone does that
- we perform quite some static analysis. Many of them are tuned to our
operational semantics and would not apply to Drools
There are many papers and at least two PhD theses were written
entirely over the compilation of CHR. Most can be found online.
Basically, we sacrifice flexibility (no runtime addition of rules,
limited conflict resolution, ...) for speed. The core language is really
fast now after several years of optimizing the compilers. Since CHR is
originally designed to specify constraint solvers, this has always been
an important factor. Lately CHR is becoming more and more (ab)used as a
general purpose language, and we are looking into adding things like
negation as absence, aggregates and flexible rule priorities, but this
is still in a very early stage.
Cheers,
Peter
Mark Proctor wrote:
> Interesting that you say its 30-100 times slower, I don't believe we
> would be much faster than jess - I'm now very intrigued to look at the
> JCHR engine :) with local search leaps wouldn't help as you want to know
> all cross products as part of the query. I should have some time early
> next year to look over this - are there any obvious things you can say
> now? Btw I have taken this conversation to the dev mailing list.
>
> Mark
> Peter Van Weert wrote:
>> Mark Proctor wrote:
>>
>>> Peter,
>>>
>>> I believe it is possible to do full prolog style backward chaining,
>>> integrated with standard rules - see
>>> http://wiki.jboss.org/wiki/Wiki.jsp?page=BackwardChaining.
>>>
>>
>> Of course it is possible. Almost every major Prolog distribution (SWI,
>> XSB, B-Prolog, SICStus 4, YAP, hProlog) includes a port of our CHR
>> system. These seemingly combine Prolog's backward chaining with CHR's
>> forward chaining.
>>
>> I agree that what you are describing on the above wiki page seems to be
>> a form of backward chaining, something I cannot always say about the
>> backwards chaining features of other rule engines (Clips, Jess, ...).
>>
>>
>>> I'm interested to see what you mean about performance, with tuning there
>>> should be no reason for our system to be less performant. See email on
>>> dev. I'm willing to apply anything to core that will make this possible.
>>> Geoff when running your examples set the following settings "-Xmx512M
>>> -Xms512M -server", I also believe there is a setting for more
>>> aggressive OO optimisations.
>>>
>>
>> Maybe I should check again. The last time I compared with Drools, it was
>> still called Drools. We recently did a comparison Jess versus
>> CHR(hProlog) though, and Jess turned out to be between 30-100 times
>> slower. This was for one of our benchmarks where the RETE versus Leaps
>> thing would not even be much of an issue. I suspect that for many other
>> benchmarks RETE will perform far worse.
>>
>> Now, let's read the mail on dev. Well, the thing is, if you can still
>> make improvements of 50%, I think you are not yet there where we are
>> with CHR. It is becoming more and more difficult to gain more then a few
>> percents with our highly optimizing compilers (not talking about JCHR
>> here, because I don't have all optimizations yet). But maybe yes, once
>> you do more aggressive optimizations and analysis, things could converge.
>>
>> What's this 'traveling tournament lvl10 use case'? If it is not to big
>> of a program, I am very interested to port it and see how (J)CHR
>> performs on it...
>>
>>
>>> Would be truly great if we can work together on a unified system - see
>>> http://markproctor.blogspot.com/2006/11/declarative-behavioural-modelling-dbm.html
>>>
>>> Of to bed as I'm shattered, I'll email tomorrow about getting together
>>> online.
>>>
>>> Mark
>>>
>>>
>>
>>
>> CHeeRs,
>> Peter
>>
>>
>>
>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>
begin:vcard
fn:Peter Van Weert
n:Van Weert;Peter
org:K.U.Leuven;Computer Science
adr:room 01.08;;Celestijnenlaan 200A;Heverlee;;3001;Belgium
email;internet:[EMAIL PROTECTED]
title:DTAI (Declarative Languages and Artificial Intelligence)
tel;work:+ 32 16 327064
x-mozilla-html:TRUE
url:http://www.cs.kuleuven.be/~petervw/
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
