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: <Cvny60.K8J@triple-i.com>
Sender: usenet@triple-i.com
Nntp-Posting-Host: pak+
Organization: Information International Inc., Culver City, CA
References: <Cv3uK5.BIw@cogsci.ed.ac.uk> <CvB1DL.6FJ@triple-i.com> <CvF292.HAM@cogsci.ed.ac.uk>
Date: Mon, 5 Sep 1994 15:39:36 GMT
Lines: 270

In article <CvF292.HAM@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>In article <CvB1DL.6FJ@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>>In article <Cv3uK5.BIw@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>
>>>You seem to be suggesting now that there's no real disagreement.
>>
>>I came to the conclusion long ago that there is little real
>>disagreement.  
>
>Sure, but that conclusion may be wrong.

[...]

I think that the most significant point of disagreement between
us about what I have been arguing for and against.

>
>But in almost every article in which you say things I think are
>reasonable you couple them stronger claims that I find less so.
>However, many times when you seem to be making a strong claim it's
>not clear exactly what it is.  Perhaps if it were clearer, I might
>agree with you.  I don't know.  

I do not know how to present my claims any more clearly.  I also am
completely baffled in what way the seem so vague to you.

>
>For instance, you mention "the kinds of applications for which I feel
>that C is better suited than current lisp implementations".  But what
>kinds of applications are those?  You wrote:
>
>  It is easy enough to say that if this feature is not useful to your
>  application and making use of it imposes too great a performance
>  burden then just don't use it.  How many such features must one
>  avoid, however, at what cost in effort and care before it becomes
>  obvious that using a language for which such issues simply do not
>  arise would have been better for that particular application?  
>  And how can one control uses of such features that are made in 
>  the run-time system unless one is also the lisp implementor?

I did indeed write the above, but I did not intend it to be (and do
not see how it could be interpreted as) a description of a kind of
application.  Rather it is one of the _reasons_ that lisp is a worse
choice, when it is a worse choice.  The _kinds_ of applications where
the above cited consideration typically causes lisp to be a worse
choice is, as I have frequently stated, system-level, real-time, and
applications with similar requirements for continuous high-bandwidth
interaction with hardware or the user which can only be achieved by
the kind of application- and hardware-specific optimization which is
C's forte.

>
>In general, you seem to be saying that when Lisp is a worse choice
>than C it's because Lisp has lower run-time performance, and at a
>number of points you've employed the "intuition that more powerful
>features impose run-time costs".  Then, the reasoning quoted as a
>block above is designed to counter the argument that Lisp should be
>judged by the speed obtainable when high-cost features are avoided.
>
>So it looks like you might be saying Lisp loses to C in every case 
>in which run-time performance is the dominant factor, even when its
>possible to write a Lisp program that's just as fast as the C program,
>because you'd have to artificially avoid the very features that can
>give Lisp an advantage over C in the first place.
>
>Of course, you might argue that all you're really saying is that
>Lisp loses when it's *difficult* to avoid higher-level features.  

Exactly.  Or it can be impossible to avoid them in some cases (mainly
the cases I assume you would attribute to poor implementation
strategies.)

>                                                                   But
>then I would ask this: 
>
>  How much scope does Lisp have to do better against C than it does
>  now?

I agree that there is room for vast improvement in both the design and
implementation of most current lisp dialects.

>
>This is the key question, and it's behind everything I've said in
>this exchange.
>
>I've tried to suggest that the scope is fairly large, at least larger
>than current experience would suggest.  Current implementations are
>misleading, better Lisp-family languages can be devised, and so on.
>You never seem to agree with me when I say such things, not even a
>qualified agreement.  On the contrary, you typically present 
>counterarguments.

But I do, and have, agreed.  I disagree that it is terribly relevent
to the topic about which I have been writing.  Again, the arguments to
which yours were a response were presented as reasons why I consider
it wrong to suggest that criticisms of _current_ implementations of
_current_ dialects on such performance grounds are unfounded, in the
context of someone being given what I considered bad advice as to what
criteria to use in choosing a programming language for any given
project.

>For instance, you say I have "not shown how implementations could be
>different in a way that mattered to any of the issues that are the
>subject of this discussion."  Against the suggestion that better
>languages could be devised, you say that when implementors do what's
>necessary you "would expect that such a Lisp would probably be as
>unsuitable for the kinds of applications for which current Lisps are
>well-suited as C is today, for all the same reasons."
>
>In short, there appears that there is a fundamental disagreement
>between us and that our aims are directly opposed.

I said that I thought there was little, not no, real disagreement.
Here is, indeed, a significant point on which we differ.  I am much
more satisfied with the current state of affairs - using a variety of
different tools for the different tasks for which each is well-suited.
I am less concerned with, and less optimistic about, the possibility
of developing some "universal" language which would be well-suited to
all or almost kinds of applications.

>I think it's wrong to suggest that we know right now which
>applications are for Lisp and which are for C or that any attempt
>to make Lisp better in one way will make it worse in another.

Again, we are just talking about different things.  I disagree with
very little in the specific points you raise below.  But the fact is
that all of these things are issues for research and future
development.  If and when lisp dialects are available which have the
properties you describe, I will be eager to apply them in areas for
which they are well suited.  In the meantime I will continue to be
quite happy using current lisp dialects where they are appropriate, C
or C++ where they are appropriate, Hypercard or Visual Basic where
they are appropriate, awk where it is appropriate, etc.

>I will therefore mention some things again:
>
>In some cases, we can develop techniques that are strictly better,
>rather than offering a different set of tradeoffs (or with the
>cost being only some thinking time).
>
>Many of the current limitations of Lisp are historical accidents.
>They are not intrinsic to the Lisp family of languages.  Had some
>different trends in Lisp development -- trends that existed -- been 
>more powerful, our impression of Lisp would now be very different.
>
>When people devise new languages in the Lisp family, they may give 
>up some features present in some other Lisps in order to gain other
>advantages.  EuLisp and Scheme don't have "eval", EuLisp makes
>redefinition an implementation and environment issue rather than part
>of the language and brings in multiple-inheritance in a different way,
>and so on.  But the resulting languages are still significantly
>different from C and they are rightly considered varieties of Lisp.
>They won't be "be as unsuitable for the kinds of applications for
>which current Lisps are well-suited as C is today".  (Though of
>course one variety of Lisp may be more suitable than is another.)
>
>Many of the things people often see as properties of (some language
>in the) Lisp (family) are actually properties of implementations.
>The same is true of C.  C _could_ be implemented inefficiently in
>a variety of ways (e.g. as an interpreter).  And Lisp often _could_
>be implemented more efficiently than it is.  Moreover, even when 
>many Lisps have the same inefficiencies, this is often due to the 
>implementation tradition (common techniques and approaches are
>reused, etc) rather than to the language.
>
>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.
>
>Finally, if Lisp is sometimes faster than C, how do you know your
>application isn't one of those cases?  It's not obvious which cases
>these are.  People have often been wrong about them.  And how is it
>that Lisp ever manages to *be* faster?  Doesn't it give a different
>impression than Kirk's "intuition that more powerful features impose
>run-time costs"?

I know from experience.

And as for "how is it that Lisp ever manages to *be* faster?"  Those
more powerful features may be necessary to some required functionality
in the application, such that it would be necessary for the
application programmer to implement them if they were missing from the
language (with the obvious likelyhood of doing a worse job than the
more powerful language's implementor would.)  Also, it is often the
case that poor performance of some particular feature is highly
application dependent - memory-management is the most frequent culprit
in my experience - such that the very same feature can either enhance
or degrade performance in different applications.

>A few closing details:
>
>>  It is also true that a language which is lacking in any built-in
>>mechanism is likely to be a better fit for applications in which
>>performance is best under some different, application-specific
>>strategy.
>
>Only if it's not too hard to discover that strategy and implement it
>and if Lisp's built-in mechanism imposes excessive costs when you try
>to implement the application-specific strategy in Lisp.
>
>>I have never stated that closures or any other feature of lisp were
>>"unacceptable". 
>
>I mean this to be clear in context, but I've looked back on it,
>and it probably wasn't.  What I objected to was the idea that it
>wasn't good enough that closures had no costs when not used.
>
>---
>
>About the burden of proof: I'm not claiming that Lisp is potentially
>as good as C in all application areas (or even that the particular
>problems Kirk's encountered can be removed.  (I don't know enough
>*about* those problems for that.)  In many cases, the only acceptable
>proof would be to produce an implementation that actually had sufficient
>performance without becoming C in all but name, and that's too much
>to expect from a few news articles.

But it is as unreasonable to expect a complete analysis of the
run-time behavior of a variety of large, complex applications in this
context.  Nor do I feel that such analysis is really required, since
even those who have felt it their duty to "defend" lisp against my
"attacks" have rarely disagreed that the kinds of performance problems
to which I have referred actually do occur for some real-world
applications written in real-world lisp implementations.

>My aims are merely to suggest that it's too soon to say which
>application areas can be handled effectively by Lisp and which
>cannot and to explain why even direct, practical experience
>with existing Lisps can be misleading.  

There is an old joke about the difference between Asian and
Western-European attitudes regarding time scales and the scope of
long-range planning:

"A conference was once held at which representatives of various
governments were asked to present their views on the affect of the
French Revolution on their countries.  The US representative delivered
a speech on the close ties between the two revolutionary movements,
and the influence on both the American Revolutionary War and the early
development of the US government by French people like the Marquis de
Lafayette.  The British representative presented a White Paper on the
profound impact that the Napoleonic Wars had on the history and
development of the UK as maritime and colonial power.  The Chinese
representative refused even to bother getting up and going to the
podium, just saying 'It's too soon to tell.'"

I do not dispute the importance and the likely positive practical
benefits of continuing to do research and development in language
design and implementation.  However, I cannot afford to take the
"mature" attitude that "it's too soon to tell" when I am required to
choose or recommend a programming language for project that must be
developed _today_.

>I am trying to suggest why the scope for Lisp to do better against
>C than it does now might be greater than people think, even when
>they have fairly good evidence and arguments on their side.
>
>-- jeff

In the mean time, until and unless the kind of research to which you
refer succeeds in producing the kinds of dialects and implementaions
to which you refer, I will continue to advocate and practice using
care when choosing or recommending what language to use for any given
project.

Kirk Rader
