Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site ittvax.UUCP
Path: utzoo!linus!decvax!ittvax!schachte
From: schachte@ittvax.UUCP (Peter Schachte)
Newsgroups: net.lang.prolog
Subject: Re: Re: metering Prolog performance: LIPS?
Message-ID: <1512@ittvax.UUCP>
Date: Mon, 1-Oct-84 11:33:20 EDT
Article-I.D.: ittvax.1512
Posted: Mon Oct  1 11:33:20 1984
Date-Received: Tue, 2-Oct-84 06:28:32 EDT
References: <2788@mit-eddie.UUCP> <19@water.UUCP>
Organization: ITT-ATC, Stratford Ct.
Lines: 54

> I have not seen anyone provide a precise specification of
> what a logical inference is (w.r.t. Prolog implementation), 
> although the notion of a Prolog inference has a precise 
> machine-independent definition.  The inference in question is
> a resolution inference; for any two complementary literals P 
> and Q, a successful unification of P and Q (i.e., generating 
> a substitution that makes P syntactically equivalent to Q) 
> sanctions the inference of the null clause.  The cost of an
> inference is the cost of successful unification plus the cost
> of applying the inference rule to derive the null clause.
> 
> In practice, the counting of LIPS is potentially misleading for
> several reasons.   For example, the actual time for any given
> unification depends on the terms being unified (e.g., constants 
> versus lists) and their internal representation as data structures
> (e.g., structure-sharing, copying, demand copying).  Another
> important consideration questions the literal meaning of ``logical
> inference;'' while failed unifications certainly consume time, they
> do not sanction any inference...should they be counted?  Still
> another consideration is that some may argue that what should be
> counted is the computational notion of ``predicate call,'' i.e.,
> the time it takes to reduce a single goal to the sequence of goals
> resulting from a successfully matched rule.   The accuracy of
> this measure if affected by such things as clause database indexing,
> data representation, even secondary storage delays in systems that
> manage external store.
> 
> Still counting LIPS seems not an unreasonable measure, and it
> is used as a rough indication of speed by nearly everyone I
> know.  It always provides a starting point in a conversation
> between two implementors, who seek further details when a large
> discrepancy in LIPS indicates some perhaps fundamental implementation
> advance.
> 
> Now that I've committed my self to the belief that the computational
> notion of a LIPS is a bit sketchy, I'm quite sure that several people
> will feel compelled to contribute their opinion.   At least I hope
> that's the case.
> 
> Cheers,
> Randy Goebel
> Logic Programming and Artificial Intelligence Group
> University of Waterloo

*** REPLACE THIS LINE WITH YOUR MESSAGE ***

	There's another potential problem with LIPS:  there's no
indication of how big the terms being unified are.  If your benchmark
involves predicates with many arguments, or involves unifying large
terms, timings will seem slow.  How big is a "logical inference?"
	A good suite of benchmmarks is probably the only way to compare
prolog implimentations fairly.  No single number will do it.

Peter Schachte (decvax!ittvax!schachte)