Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bellatrix.uucp!vanroy
From: vanroy@bellatrix.uucp
Newsgroups: comp.arch
Subject: "General-purpose" architectures and symbolic languages
Message-ID: <28113@ucbvax.BERKELEY.EDU>
Date: 21 Feb 89 20:25:30 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: vanroy@bellatrix.uucp ()
Organization: University of California at Berkeley
Lines: 31


  Does anyone know of any comparisons of algorithms implemented in symbolic
languages (i.e. Prolog/Lisp) without any special annotations versus in an
imperative language?  This involves writing the algorithm in a natural style
in both languages, and using high-performance (perhaps experimental) compilers
to compare the execution speeds.  The results depend on many factors:
(1) the choice of algorithm, (2) programming style, (3) the quality of the
compilers, and (4) the suitability of the architecture for the symbolic
language.
  I know of one comparison done at Argonne in which a theorem prover was
written in Prolog and in C.  The C version consistently outperformed the
Prolog version by an order of magnitude.  This was due to (1) the poor
implementation of arrays in the Prolog version and (2) the awkwardness of the
architecture for Prolog (I believe it was a Sun-3).  Has anyone done any other
such comparisons?
  Present-day general-purpose architectures will naturally favor the imperative
language in a comparison of this sort.  This is because the traditional notion
of "general-purpose" architecture is not truly general-purpose.  It emphasizes
numeric calculation and does not do the things that symbolic languages require,
such as tag manipulation and multiway branching.  Therefore I propose that the
notion of "general-purpose" be extended to include support for symbolic
languages.
  At Berkeley, we are developing such an architecture for the Prolog language.
We are designing it from the start as a complete system, i.e. compiler,
instruction set architecture, and (single-chip) implementation are being
developed together with feedback in all directions.  In this way we hope to
overcome some of the limitations of previous implementations of Prolog.
  Thanks for any pointers,

	Peter Van Roy
	vanroy@bellatrix.berkeley.edu