Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!news.duke.edu!news-feed-1.peachnet.edu!gatech!swrinde!pipex!bt!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: <CvF292.HAM@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: <Cuzw9q.6Gw@triple-i.com> <Cv3uK5.BIw@cogsci.ed.ac.uk> <CvB1DL.6FJ@triple-i.com>
Date: Wed, 31 Aug 1994 20:29:25 GMT
Lines: 169

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 agree with many of the things
you say.  For instance, you're right to point out that that different
tools are better suited to different tasks, that different languages
are optimized for different kinds of applications, that greater
expressive power has costs, etc, and that an implementation might
use a feature the programmer avoids, thus negating the programmer's
efforts.

I also agree that there are classes of applications for which current
C is better than current Lisps and that it's wrong to offer as advice
"that lisp is well suited to all or nearly all kinds of applications,
that it is really not necessary to worry too much about performance
issues since tools exist for tuning executables, etc."

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.  

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?

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.  But
then I would ask this: 

  How much scope does Lisp have to do better against C than it does
  now?

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.

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

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.

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.  

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
