Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!bloom-beacon.mit.edu!gatech!news.sprintlink.net!simtel!harbinger.cc.monash.edu.au!yoyo.aarnet.edu.au!munnari.oz.au!cs.mu.OZ.AU!mundil.cs.mu.OZ.AU!conway
From: conway@mundil.cs.mu.OZ.AU (Thomas Charles CONWAY)
Subject: Re: speed of prolog
Message-ID: <9514909.20139@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU (CS-Usenet)
Organization: Computer Science, University of Melbourne, Australia
References: <3pam2e$9jh@chuangtsu.acns.carleton.edu> <3pptgj$6do@percy.cs.bham.ac.uk> <D90wt4.32n@cee.hw.ac.uk>
Date: Sun, 28 May 1995 23:09:06 GMT
Lines: 47

andrew@cee.hw.ac.uk (Andrew Dinn) writes:

>Oh dear. The answer here is almost as irrelevant as the question. A
>language can hardly be described as slow or fast per se. Firstly, it
>depends what you try to do with it. So *programs* are fast or slow,
>not languages. Secondly, even if one resorts to picking a particular
>task and coding it in say Prolog and C++ that might tell you something
>about the job in hand and might indicate some likely corollaries when
>it comes to coding other (similar) tasks but it might also just tell you
>something about the compiler or operating system you are using or even
>your ability as a coder in these two languages. So much depends.

It is also true that different implementations of the same language
can differ greatly in the quality of the executable code that they
yield. Parma (Taylor, 1991) was an experemental Prolog implementation 
written to show that Prolog itself is not inherently inefficient,
but rather that current implementations do not do the best possible
job of producing fast executables.

Interestingly enough, there has been discussion in comp.compilers
recently debating the relative efficiency of C and C++. I don't
want to get involved in that argument, but the point was well raised
that C++ implementations are currently not nearly as good as they
could be becuase they are mostly C++ front ends, bolted on to
C back ends and optimizers. Thus most C++ compilers don't optimize
virtual function calls *properly*, etc.

One of the issues for Prolog is that it takes a lot of heavy analysis
to discover the information that the compiler needs to make a good
job of compiling the code. For a lot of Prolog's lifespan, the amount
of computational resources needed for this analysis has been quite
prohibitative, so to get acceptable performance, Prolog has had
to rely on programmers using tricks like difference lists, cuts,
assert/retract, etc. When these language features were introduced
it was arguably the right tradeoff. (All language design is about
tradeoffs of one kind or another.)

Unfortunately, the {extra,non}-logical features of Prolog also make
analysis more difficult, and in some cases require that poor
approximations be taken which compromise the effectiveness of the
information that the analysis yields. Thus, if Prolog compilers
continue to improve (building on work like Parma and Aquarius),
it will become more the case that a program that uses these
efficiency hacks will perform worse than if it had been written
without them.

Thomas
