jeff@aiai.ed.ac.uk (Jeff Dalton) (06/15/90)
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