Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!Germany.EU.net!Frankfurt.Germany.EU.net!news.maz.net!news.ppp.net!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Message-ID: <1996Feb26.121927.25154@wavehh.hanse.de>
Organization: BSD User Group Hamburg
References: <s08enrkxymc.fsf@lox.ICSI.Berkeley.EDU> <4gnu92$ll8@ra.nrl.navy.mil>
Date: Mon, 26 Feb 96 12:19:27 GMT
Lines: 99

pitre@n5160d.nrl.navy.mil (Richard Pitre) writes:

>In article <s08enrkxymc.fsf@lox.ICSI.Berkeley.EDU>  
>marcoxa@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
>> In article <4glcki$l6g@frigate.doc.ic.ac.uk> ap14@doc.ic.ac.uk (Alex Pfister)  
>writes:
>> 
>>    From: ap14@doc.ic.ac.uk (Alex Pfister)

>>    I was told that compiled Prolog code is on the average about twice
>>    as slow as comparable code written in C, Pascal.
>>    How is the performance of Lisp compared to other programming languages?

Good C compilers can produce as overhead-free code as C compilers does.

Two problems: 

1) Modern RISC machines needs more than the shortest sequence of
instructions, they need the instructions to be sheduled in a certain
order. Usually, only the compiler writers of the chip makers can
provide optimal sheduling and they usually write C and Fortran
compilers. Even gcc has many problms in this area. Most Lisp
implementations doesn't care about sheduling at all. On Mips
systems I've seen CMUCL producing faster code than gcc for exactly the
same (floating point) algorithm.

The flip side is that a compiler like CMU CL, which has a much higher,
cleaner abstraction of the code generation process may be tuned easier
for such processors than most C compilers. gcc needs a complete new
design of an interafce, some kind of abstraction to provide the
neccessary information about each CPU's preferences. I claim this is
easier to do in Lisp.

2) CL compilers generate good code for build-in data types. But CLOS
types require dynamic lookup. C++ can do static binding and therefore
inlining. This can be a big plus when using small
objects. Additionally, the dynamic lookup of C++ is very efficient,
about twice as fast as that of ObjC (which needs two
indirections). CLOS is much worse. An additional problem is that most
(if not all) CLOS implementations arrange slots using pointers, which
causes one additional access and CPU cache trashing. As I understand,
the required flexibility of CLOS makes it difficult to lay out Slots
as direct values because one needs to be able to redefine the type of
these slots.

The right way might be too look at what Dylan does and see in what way
their sealing type system is useable in a Common Lisp
environment. Would at least require some additional semantics for
packages/modules, I think.

CL can provide good performance but you have to have performance in
mind when you start a project. Most CL programs of mine started as a
very flexible piece of code that has too many dependencies on slow
method lookup in it to change it later.

And don't forget that it requires a good Lisp compiler and a
programmer who understands his compiler. I can't claim to fall into
this category, although I usually get my programs fast enough. In C++
that is not so important.

>> About as fast if you use a good compiler as CMUCL (where available).
>> On the other hand I just read some post elsewhere (was it
>> comp.lang.dylan ?!?) where ther was somebody complaining that using
>> the C++ STL slows the system down to about half (well, maybe a bigger
>> fraction :) ) the speed of a good CL implementation :)

The STL is one of the nicest pieces of C++, IMHO. Used carefully, it
can be very useful to control the performance characteristic of a
program. I'd say "pilot error" or braindead implementation when code
slows down when using STL. Maybe someone could tell them that <MAP> is
not a hashing data type. This alone is the cause of many
slowdowns. People tend to think that a data type such as map is the
fastest possible implementation. Remember that C++ is a language that
is designed by very good people, but that the average user is much
less experienced as members of the Lisp community these days (my
impression).

>Correct me if I'm wrong about these speed tests but I think that they tend to  
>be done on C/Pascal turf. If on the other hand the primary data types are  
>expression trees of indeterminate size and there is pattern matching involved  
>then, before you get to the speed issue, there is a question in the minds of  
>many about the availability of C/Pascal programmers who can reliably generate  
>useful code of this type. 

Right, I think. However, you can get very far with simple data types
when using enough manpower. All this GUI stuff today is implemenated
that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).

Your argument may be turned against CLOS. Using complex data types in
Common Lisp usually means loosing all support by the compiler, while
C++ doesn't care and produces the same code for "1 + 1" in most cases,
even when expressed as call to an object.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>  -  Fax +49 40 522 85 36
 BSD User Group Hamburg, Germany   -   No NeXTMail anymore, please.
 Copyright 1995. Redistribution via Microsoft Network is prohibited
