Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!news.hal.COM!halsoft.com!netcomsv!torii!kirk
From: kirk@triple-i.com (Kirk Rader)
Subject: Re: C is faster than lisp (lisp vs c++ / Rick Graham...)
Message-ID: <Cw1DEr.L4E@triple-i.com>
Sender: usenet@triple-i.com
Nntp-Posting-Host: pak+
Organization: Information International Inc., Culver City, CA
References: <HJSTEIN.94Aug31213301@sunset.huji.ac.il> <Cvo01H.KLI@triple-i.com> <Cvtoq2.21v@cogsci.ed.ac.uk>
Date: Mon, 12 Sep 1994 21:37:38 GMT
Lines: 45

In article <Cvtoq2.21v@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

[...]

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

This is not a "problem" with the point I was making, since I have been
making a point about the state of the art _today_.

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

Anyone who has spent time wringing a few processor cycles out of a
real-time application should be able to understand why even trivial
costs of high-level features can often be of great concern.

[...]

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

Then why have you considered it so important to dispute its truth?

[...]

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

I have repeatedly said that I do not believe that lisp is always
slower than C.  I just think that the opposite is at least as often
the case.

Kirk Rader
