Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcomsv!torii!kirk
From: kirk@triple-i.com (Kirk Rader)
Subject: Re: C is faster than lisp (lisp vs c++ / Rick Graham...)
Message-ID: <Cvo01H.KLI@triple-i.com>
Sender: usenet@triple-i.com
Nntp-Posting-Host: pak+
Organization: Information International Inc., Culver City, CA
References: <HJSTEIN.94Aug25170544@sunset.huji.ac.il> <CvB394.6tt@triple-i.com> <HJSTEIN.94Aug31213301@sunset.huji.ac.il>
Date: Mon, 5 Sep 1994 16:20:05 GMT
Lines: 98

In article <HJSTEIN.94Aug31213301@sunset.huji.ac.il> hjstein@sunset.huji.ac.il (Harvey J. Stein) writes:
>Why are you arguing with me?  First you say that a "more featureful
>(sic)" language must be "a priori" more inefficent.  I gave a
>counter-example, and now you say that some features need not impact
>efficiency.  So, which is it going to be?

I am arguing with you because I believe you to be in error in your
criticism of my previous posting.  The more powerful features of C++
which you posed as a counter-example do not impose a greater run-time
burden because they are just syntatic conveniences that by the design
of the language have no affect on the run-time behavior of the
language.

>"I do not believe" is not good enough.  Since, as you now admit,
>additional features do not "a priori" imply overall language
>inefficiency, you must, to prove that lisp is more inefficent than C
>(the original conjecture), take particular features of lisp, and prove
>that they they must, regardless of implementation, force lisp to be
>more inefficient than C, even when these features aren't used.  Good
>luck.

I admit that purely syntactic features do not impose a run time
overhead.  I have no intention of starting this whole interminable
thread over again by repeating the many examples of lisp's features
imposing an unacceptable overhead on certain kinds of applications.  I
repeat, the burden of proof is on those who claim that it is possible
to retain all or even most of current lisp implementations' features
while eliminating all of the run-time performance problems that they
entail for real-time, system-level, or highly interactive
applications.

[...]

>Well, then, what happened to the performance hit that these features
>were supposed to cause?  What's your argument now - that the misuse of
>powerful features can cause inefficiencies?  Sure - in ALL languages!
>And, no, you haven't been explicitly talking about cases where...  You
>said several paragraphs back that high level features "a priori" make
>a language inefficent, WITHOUT EVEN QUALIFYING THAT THEY MUST BE USED,
>let alone be improperly implemented or improperly used.

Experience has shown that some applications perform better written in
lisp than in C.  This does not imply that lisp's more powerful
features do not result in higher run-time performance overhead
relative to C, just that there are applications for which the
advantages those features confer more than outweigh any cost they
impose.

[...]

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

[...]

>Your remark is just untrue.  If you paused long enough to read what I
>wrote, you'd see that I didn't say that all features of lisp are
>optimally implemented in all implementations, and I never asserted
>that all the features of all lisp implementations never cause overall
>performance hits (multiple return values comes to mind).  This is all
>you're refuting.  What I said, which I'll restate on the off chance
>that you might actually read it, is that powerful features do not
>imply inefficiency.  And I said it in response to your comment that
>they do.

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

>
>Now, if you'll excuse me, I'm not going to reply to this thread again
>because it's gotten too inane.
>
>Enjoy yourself,
>
>--
>Harvey J. Stein
>Berger Financial Research
>hjstein@math.huji.ac.il

Same to you.

Kirk Rader
