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)