Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uknet!festival!edcogsci!usenet
From: tfb@cogsci.ed.ac.uk (Tim Bradshaw)
Subject: High-level features can be fast (was Re: C is faster than lisp)
In-Reply-To: jeff@aiai.ed.ac.uk's message of Wed, 31 Aug 1994 20:29:25 GMT
Message-ID: <TFB.94Sep1015231@oliphant.cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: oliphant
Organization: Centre for Cognitive Science, University of Edinburgh
References: <Cuzw9q.6Gw@triple-i.com> <Cv3uK5.BIw@cogsci.ed.ac.uk>
	<CvB1DL.6FJ@triple-i.com> <CvF292.HAM@cogsci.ed.ac.uk>
Date: Thu, 1 Sep 1994 00:52:31 GMT
Lines: 25

Note that this is a small quote from a large article, but this is
something that I just thought of.  It also *isn't* meant to be
specific to lisp, although the example is from common lisp, that being
the language I am most familiar with.

* Jeff Dalton wrote:

> Now, what exactly are the costs of higher-level features?
> Some costs can be moved to compile-time.  (Not all.  It's not
> for nothing that I said "a priori" before and put a ":->" after
> "it can all be handled at compile-time.")  Other costs are small.
> There are plenty of cases where C is now better than Lisp but
> where Lisp might be preferred if the cost was, say, 10% rather
> than a factor of 2.

And sometimes the costs can be negative.  For instance consider LABELS
in Common Lisp.  A good compiler (even a dumb one I expect) ought to
be able to compile very fast calls to the local functions so
established and very fast references to the data they share.  This is
certainly true of CMUCL -- the difference between two simple
self-recursive functions to count to a number seems to be about a
factor of 5.

--tim

