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: <CvGM8E.Hsy@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> <HJSTEIN.94Aug25170544@sunset.huji.ac.il> <CvB394.6tt@triple-i.com>
Date: Thu, 1 Sep 1994 16:38:37 GMT
Lines: 105

In article <CvB394.6tt@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <HJSTEIN.94Aug25170544@sunset.huji.ac.il> hjstein@sunset.huji.ac.il (Harvey J. Stein) writes:

>Lisp, on the other hand, has a much richer run-time semantics than
>either C or C++ which cannot be interpreted as mere syntactic sugar.
>I do not believe it possible to obtain those rich run-time semantics
>without paying a cost for them in executable size or speed.

Which features and how much cost?  1%?  10%?  Small integer factors?

Of course, "rich run-time semantics" is aimed at taking the claim
closer to tautological, by suggesting that things handled at compile
time aren't part of the "richer" semantics.  But in fact the semantics
of Lisp allow a range of implementations in which costs can often be
moved from run-time to compile-time (if they'd even occur at run-time
in the first place.)

It's pointless to continue at this abstract level.  All we get then
is that it looks like there will be unavoidable costs.  But are they
really unavoidable, and how much can they be reduced?  How central
are the features to Lisp?  How much trouble will it be to avoid
them, if that's what's needed?

>>Furthermore, some features could enhance performance.  For example,
>>suppose one were to add some set of data structures to a language, and
>>implement them extremely carefully with optimal performance.  Further
>>suppose that it would be difficult to code an efficient implementation
>>of these data structures in the original language.  Then, you would
>>have enhanced the language, and made it more efficient in the cases
>>that these data structures are used in the optimal implementation.
>
>Your argument is circular.  Of course a more powerful language will be
>better for applications which make use of those extra features in an
>optimal way.  I have been explicitly talking about cases where the
>extra features of the more powerful language do not pay for themselves
>either because they are not well implemented or are not necessary to
>the particular application.

He said optimal implementation, not applications which use the
features in an optimal way.

In any case, he has a perfectly valid point.  Imagine an application
A that could make good use of a data structure D but where the people
writing C programs for A don't use D because it's too hard to implement
D efficiently in C.  Then along comes HJS with an extended C that
includes D and implements D efficiently.

Now for ther cases Kirk is "explicitly talking about".  If the
extra features are not well implemented, perhaps they could be
well implemented.  then we have an implementation problem, not
a language problem.  If the extra features are not necessary,
then perhaps they won't be used or will be used only in parts
of the application that are not performance-critical.

Without knowing what the applications, features and costs are, we
can't say whether it has to be a problem that a language has those
features.

>>Moreover, one would hope that all language feature are implemented
>>carefully and as efficiently as possible, and thus one would expect
>>that using these features would produce faster code than implementing
>>them oneself.  So, using these features in the cases where the
>>alternative is to code them oneself probably leads to higher
>>performance, not lower performance.
>
>One would hope so, but sadly that is not always true.  

Of course it's not *always* true!

>>   *Having* features doesn't make a program slow, *using* them makes
>>   it slow.
>>
>>So, you can't argue that LISP must be slower than C just because it
>>has more features.
>
>This last point is just untrue.  Some features impose run-time costs
>whether they are in use by a particular application or not. 

Which features?  How much cost?

>Jeff Dalton, whom you would presumably consider to be on your "side" in
>this, explicitly referred to such in one of his recent posts.

Multiple-values, perhaps?  The cost is fauily small, and most
Lisp-family languages don't have multiple-values.  I therefore
conclude that we can remove that feature from the language without
ceasing to be Lisp or losing important Lispish advantages.  It may
also be possible to change the semantics to reduce the costs further
while not giving up benefits anyone cares about.

>  And in
>addition, the presence of features implies that you and the language's
>implementors must exercise care to not use them when they are not
>appropriate.  It is this last which can frequently result in it being
>more trouble than it is worth to use a more powerful language than is
>required for a partiular application.

Well, there is a significant Lisp problem in this area that we might
agree about, namely that it's often not clear what will be efficient.
If it were clearer, and if implementations were more consistent (with
each other), then it would be easier for "good practice" to develop
and be taught, which would increase the range of applications for
which Lisp was not too much trouble.

-- jeff
