[mod.ai] Turbo Prolog

Tim@UPENN.CSNET (Tim Finin) (03/12/86)

Ken and Chuck,

I sent the following message about a newly announced prolog compiler
which did not show up in either mailing list.
   
   From: Tim Finin <Tim@UPenn> on Thu  6 Mar 1986 at 15:51, 13 lines
   To:   AIlist@sri-ai, PROLOG-REQUEST%su-score.arpa@CSNET-RELAY
   Subj: Turbo Prolog
   Date: Thu, 6 Mar 86 15:51 EST
   
   Someone gave me a copy of a news item from Electronic Engineering Times of
   March 3rd which describes a Prolog compiler for PCs that Borland Int.
   (of Turbo Pascal fame) is releasing on April 15th.  According to the note,
   the price will be $99.  Borland claims that it was clocked at 100K lips on
   an IBM-PC and 300K lips on an AT! (The benchmark used was described as "a
   single rule benchmark").  The dialect is described as "a superset of
   Clocksin and Mellish".
   
   The system appears to include an incremental compiler, screen editor,
   support for windowing, a module capability, sound primitives and color
   graphics primitives.
   
I assume you both thought it was too much of a plug for a new compiler with
little real significance.  I disagree!  It is significant for one of two
reasons, as I explain below.  Note first that:

	1 - Borland is a respected company making  software for micros.
            Their products, especailly Turbo Pascal, are quite good, widely
            used and very cheap.  I've seen it claimed that over 500,000
	    copies of Turbo Pascal have been sold!
	2 - Their prolog compiler seems to be reasonable from the point of
	    view of features.
	3 - It's claimed to provide a ORDER OF MAGNITUDE improvement on
	    performance.  The other PC based prolog compiler claim to run
	    on the order of 10K to 20K Lisp, I think.  
	4 - They are claiming to sell it at an ORDER OF MAGNITUDE less price
	    than the other prolog compilers for PCs.

Now - the reasons: either (1) Borland has discovered some very clever tricks
to producing much better compiled code from standard prolog or (2) they are
not playing the benchmarking game fairly.  I tend to lean toward (2) but
hope that there may be a fair amount of (1) involved as well.  If Turbo
Pascal weren't such a win, I'd have little hope.  On the pessimistic side,
Robert Rubinoff sent me the following back-of-the-envelope analysis:

     From: Robert Rubinoff <Rubinoff@UPenn> on Fri  7 Mar 1986 at 10:28,
     To:   Tim Finin <Tim@UPenn>
     Subj: Turbo Prolog
     
     100 Klips = .1MHZ.  Now assuming that they are only using code within
     one segment (which limits you to 64K), the 8088 takes about 3 cycles
     for the average register instruction, and about 10-15 cycles + memory
     fetch time for a memory instruction.  Memory fetches take a few cycles;
     I can't find where it says how much; so let's say that it's just enough
     to push the average instruction time up to 15 cycles.  If 2 out of 3
     instructions are register instructions, we get an average of 21/3 or 7
     cycles per instruction. (I think my calculations here are probably a
     little low).
     
     So if we have a 4MHz 8088, we get an instruction rate of 0.5MHz, or 5
     instructions per lip.  On an 8MHZ 8088, we get 10 instructions per
     inference. That strikes me as not enough.  Maybe they're using a
     benchmark that doesn't do any unification.
     
     And all of this (at least on the 8088 in the PC, I don't know about the
     AT) requires that everything be in the same segment.  If you want more
     than 64K, you have to go to multiple segments, which slows things down
     a lot.
     
     I'm dubious. But we'll see, I guess.
     
     Robert

Anyway, when a respectable, established company offers a basic AI tool which
jumps TWO ORDERS OF MAGNITUDE on the price/performance scale, I think its
news!  If a few months we'll either be praising the cleverness of the
Borland programmers or cursing the dishonesty of the Borland marketing
people.

Tim

  [Actually, Tim's message was simply the victim of "digest delay"
  and of my recent full schedule.  It had come to the head of the
  queue and would have been sent out today in any case.  Most messages
  are redistributed within a week, although humor and "special issue"
  messages are sometimes saved for two weeks in order to collect a
  sufficient number on the same topic.  Authors of "commercial
  messages" which must be rejected will receive a note from me
  (unless the message has already gone out on UUCP net.ai).  Tim's
  message is well within the limits of acceptability (and usefulness --
  thanks, Tim!).  The posting which follows is more dubious, but seems
  to be forwarded in a spirit of helpfulness rather than commercial PR.
  A discussion has just started on WorkS, Human-Nets, and Large-List-People
  that may redefine the limits of acceptability, particularly with respect
  to including price information.  (While price is obviously an important
  spec, it has been one of the touchstones for identifying messages
  with commercial intent.)  -- KIL]

ted@nmsu.CSNET (06/22/86)

Recent reviews have correctly pointed out that turbo prolog's
attempt to enforce type checking has both good and bad points and
that the speed is not very impressive, since much of the
unification can be done at compile time if data types are known.

The major difficulty with Borland's approach to adding strong
typing to prolog is the loss of higher-order predicates.  Since a
domain can be at most the disjunction of a small number of
_predeclared_ terms, it is impossible to write a general higher-
order procedure.

This means that you can't write findall, as described in Clocksin
and Mellish (Borland has of course, in their wisdom, provided
such a function).  The function doall also cannot be written.  It
is handy as a substitute for findall when the predicate Q is
executed for effect only.

	doall(Q) :- Q,fail.
	doall(_).

First class procedural objects are, in many senses, a much more
fundamental distinction between symbolic and conventional
languages than are heap allocated data structures.  Their loss
makes many advanced applications nearly impossible.

cornish@RUSSIAN.SPA.Symbohics.COM (jan cornish) (09/17/86)

I've heard some chilling things about Turbo Prolog. Such as

1) The programmer must not only declare each predicate, but also whether
each parameter to the predicate (not correct terminology) is input
or output. This means you can't write relational predicates like
grandfather.

2) The backtracking is not standard.

3) "You can do any thing in Turbo Prolog that you can do in Turbo Pascal"

I want to hear from the LP community on Turbo Prolog as to it's ultimate
merit.  Something beyond the dismissive flames.  

Thanks in advance,

Jan

Laws@SRI-STRIPE.ARPA (Ken Laws) (09/23/86)

For another review of Turbo Prolog see the premier issue of AI Expert.
Darryl Rubin discusses several weaknesses relative to Clocksin-and-Mellish
prologs, but is enthusiastic about the package for users who have no
experience with (i.e., preconceptions from) other prologs.  The Turbo
version is very fast, quite compact, well documented, comes with a
lengthy library of example programs, and interfaces to a sophisticated
window system and other special tools.  It could be an excellent system
for database retrieval and other straightforward tasks.  His chief
reservation was about the "subroutine call" syntax that requires
all legal arities and argument types to be predeclared and does not
permit use of comma as a reduction operator.

					-- Ken Laws
-------