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: <Cvtoq2.21v@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: <CvB394.6tt@triple-i.com> <HJSTEIN.94Aug31213301@sunset.huji.ac.il> <Cvo01H.KLI@triple-i.com>
Date: Thu, 8 Sep 1994 18:01:14 GMT
Lines: 55

In article <Cvo01H.KLI@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <HJSTEIN.94Aug31213301@sunset.huji.ac.il> hjstein@sunset.huji.ac.il (Harvey J. Stein) writes:

>Experience has shown that some applications perform better written in
>lisp than in C.  

There are few things that have been written in both Lisp and C
by equally skilled programmers, and the Lisp implementations
used typically have known, correctable deficiencies.  What
experience shows is very specific.

>>Here we go again...  Once more.  Yes.  It can be the case that using a
>>particular feature in a particular application is inefficient.  This
>>does not mean that lisp is inefficient, just that the programmer is an
>>idiot.
>
>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.  Common Lisp's treatment of both argument lists
>and multiple return values are frequently cited examples (including by
>yourself, below.)

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.)

  * 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.

>I will continue to believe that more powerful features do in general
>imply more overhead, until someone succeeds in showing how such
>overhead could always be avoided, which you have not.

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.

>  What you said
>in the preceding paragraph is that you can reduce run-time overhead by
>eliminating features, which I have never disputed.  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?)

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

-- jd
