🚀 go-pugleaf

What was missing form the original article was an explanation of why
the Prolog result was faster.  Without that, we can't learn all that
much from it.  Two examples may serve to illustrate this point.

I have done Lisp vs C comparisons for TAK in the past.  Some results
showed Franz Lisp being faster than C.  Lisp arithmetic can be as fast
as C, but it would be unusual to find that it was faster.  However,
this was on a VAX, and a little thought suggested that what was really
being shown was that Franz implemented procedure calls more efficiently.
Indeed, "local" functions in Franz are called by JSB (or whatever the
VAX instruction is) while the C call was using CALLS.

Of course, C could use JSB, so my result did not show that the Franz
Lisp language was faster than C, just that certain implementations on
certain machines could produce certain results.

A more fun example is that Kyoto Common Lisp was faster than C
on a Sun3.  This cries out for explanation, because KCL compiles
Lisp by translating it into C.

So this Prolog vs C result doesn't show that this Prolog is faster
than that C on arithmetic.  It might be procedure calls or something
else that accounts for it.  I at least would be interested in knowing
what and whether C could do it too.  Perhaps Richard O'Keefe is
right to suggest that it's "_really_ cheap" procedure calls.

However, before going on I think we ought to bear in mind that the
original article said:

  Disclaimer: this benchmark has a particularly easy translation to C.
  The result does not necessarily hold for other programs.  But don't
  you believe it anymore that Prolog is slow!

Ok, maybe Prolog is still slow at everything else; but it's clear
that no one was really trying to claim otherwise.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton