dowless@sae.sae.com (Alan Dowless) (01/09/91)
Scott,
I'm sending you the comparable knowledge base that I
ran with KES 3.0 on a SUN Sparc 1. This knowledge
base simply fires "init rule" 30000 in 23 seconds.
This calculates to: 78260 rule firings per minute.
If you haven't talked to Tamara Huebschman, call her
and she will be happy to send you out an evaluation
copy of KES 3.0.
Thanks, Alan
attributes:
f:int.
y:int [default: 30000].
%
rules:
init rule:
if true then
reassert f=1.
endif.
%
actions:
while y # 0 do
obtain f.
erase f.
reassert y= y-1.
endwhile.
%acha@CS.CMU.EDU (Anurag Acharya) (01/11/91)
In article <7441@uklirb.informatik.uni-kl.de> dowless@sae.sae.com (Alan Dowless) writes: > I'm sending you the comparable knowledge base that I > I ran with KES 3.0 on a SUN Sparc 1. This knowledge > base simply fires "init rule" 30000 in 23 seconds. > This calculates to: 78260 rule firings per minute. > Thanks, Alan > attributes: > f:int. > y:int [default: 30000]. > % > rules: > init rule: > if true then > reassert f=1. > endif. > % > actions: > while y # 0 do > obtain f. > erase f. > reassert y= y-1. > endwhile. > % This particular benchmark means almost nothing. The task is so simple that it can be coded in languages with a wide range of expressiveness. And it bears no similarity to the sort of programs that will eventually be written/run on the system. The primary characteristic of production system languages (call them shell languages if you will) is their pattern matching power. This benchmark makes no attempt to exercise it in any way. In this case, the comparison is between a single rule firing 30000 times (from the original post on CLIPS) and a single rule causing a C-like loop to be executed 30000 times (in this example). There are a set of production system languages (like the one used in the example), whose working memory consists of a set of variables declared at the top of the program and the match conditions consist of C-like predicate tests on the values of these variables. The pattern-matching power of such languages is puny compared to that of OPS5, OPS83, CLIPS and similar languages. Such languages are little more than syntactically sugared versions of C-like languages. anurag
timm@runx.oz.au (Tim Menzies) (01/20/91)
In article <7463@uklirb.informatik.uni-kl.de> acha@CS.CMU.EDU (Anurag Acharya) writes: >In article <7441@uklirb.informatik.uni-kl.de> dowless@sae.sae.com (Alan Dowless) writes: [stuff deleted re rule-based performance tests] I think that having some way of comparing different rule systems is a good idea. May I suggest that the comparision be based on that old favourite, the missionary & cannibal problem? -- _--_|\ Tim Menzies (timm@runxtsa.oz) / \ HiSoft Expert Systems Group, \_.--._/ 2-6 Orion Rd, Lane Cove, NSW, 2066 61 2 9297729(voice),61 2 4280200(fax)
mikeb@wdl31.wdl.loral.com (Michael H Bender) (01/24/91)
In article <7478@uklirb.informatik.uni-kl.de> timm@runx.oz.au (Tim Menzies) writes:
I think that having some way of comparing different rule systems is a good
idea. May I suggest that the comparision be based on that old
favourite, the missionary & cannibal problem?
I am very doubtful about the idea of having a single benchmark for
comparing different rule systems. What would the results mean? That the
shell was very good for solving the Missionary and Cannibal Problem? In all
my years of programming, I have never once been asked to write a fast
program to solve that particular problem.
The only time that benchmarks have value is when you have a whole series of
different benchmarks (such as the Gabriel Benchmarks) that each measure
different characteristics of the system, or the same characteristic under
different conditions. Otherwise, it seems like a pointless activity.
Mike Bender