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!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: C is faster than lisp (lisp vs c++ / Rick Graham...)
Message-ID: <Cw367s.8I0@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <Cvo01H.KLI@triple-i.com> <Cvtoq2.21v@cogsci.ed.ac.uk> <Cw1DEr.L4E@triple-i.com>
Date: Tue, 13 Sep 1994 20:57:28 GMT
Lines: 62

In article <Cw1DEr.L4E@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <Cvtoq2.21v@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

>>There are several problems with this point, of which I will mention
>>two:
>>
>>  * We don't always know what can be compiled away, and what's
>>    actually compiled away changes as new methods are developed.
>>    (BTW, multiple-value overheads-when-unused could be compiled away 
>>    by a global analysis.  Unfortunately, CL has some properties
>>    that make that difficult.)
>
>This is not a "problem" with the point I was making, since I have been
>making a point about the state of the art _today_.

What you wrote was:

  Or that the design of the language includes requirements which it is
  impossible to "compile away" even if the application does not make
  explicit use of them.

"Impossible", not "currently beyond the state of the art".

>>  * Even when something isn't compiled away, the cost may be trivial.
>>    Since you (Kirk) don't say what the costs are, it's hard to say
>>    whether it makes sense to care.
>
>Anyone who has spent time wringing a few processor cycles out of a
>real-time application should be able to understand why even trivial
>costs of high-level features can often be of great concern.

Exactly, *can* be.  I want to know how great the cost is so I
can tell when it will matter for myself.

>>And I will continue to believe that what matters is how great
>>and exactly what the overheads are.  That there are bound to be
>>some overheads somewhere is not a point worth making.
>
>Then why have you considered it so important to dispute its truth?

Because it hasn't been shown.

>>For many applications it's already the case.  Or do you want to
>>say Lisp is always slower than C?

>I have repeatedly said that I do not believe that lisp is always
>slower than C.  I just think that the opposite is at least as often
>the case.

You wrote:

  If you reduce lisp's features to the point where it has no
  additional run-time overhead, what makes you think it will have
  retained any additional features (other than purely syntactic ones
  such as those which C++ has over C?)

Lisp can be as fast as C for some things despite retaining
features.  What makes you think it will have to give up the
features in other areas?  (I assumed, BTW, that you *agreed*
Lisp wasn't always slower.)

-- jeff
