Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!swrinde!howland.reston.ans.net!ix.netcom.com!netcom.com!wnewman
From: wnewman@netcom.com (Bill Newman)
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Message-ID: <wnewmanDnF37p.FC2@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <s08enrkxymc.fsf@lox.ICSI.Berkeley.EDU> <4gnu92$ll8@ra.nrl.navy.mil>
Date: Tue, 27 Feb 1996 04:31:01 GMT
Lines: 111
Sender: wnewman@netcom8.netcom.com

Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:
: 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:
: > 
: >    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?
: > 
: > WARNING: FLAME BAIT AHEAD!
: > 
: > 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 :)
: > 
: > Cheers
: > -- 
: > Marco Antoniotti - Resistente Umano
: > 

: TAKING THE BAIT

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

: richard

One data point to consider: the world of computer game-playing
programs (programs to play Chess, Go, Bridge, or whatever) seems to be
dominated by programs in C and increasingly C++, with critical parts
hand-coded in assembler where programmer time is available and
portability isn't an issue.

I know something about computer chess (I read the newsgroup..) and I
don't know of any programs not in C, C++, or assembler.  (Except that
for a time, CRAY BLITZ used the Cray FORTRAN compiler.)

In Go (my particular interest) expansion trees of indeterminate size
and pattern matching are fundamental, and the three strongest programs
which I'm familiar with (including the current world champion and two other
programs which are almost certainly in the top ten) are

   Handtalk (the current world champion and a newcomer this year, written
     entirely in 80x86 assembler(!) by a chemistry professor in 
     mainland China);

   Many Faces of Go, written in C by David Fotland at HP; he has said that
     it would be in C++ if done today, but it's been around for a decade
     or so and that C++ wasn't an attractive option when he started; and

   Nemesis, by Bruce Wilcox, who originally wrote
     the program in Lisp (as an academic project?) and ended up translating
     it to C for efficiency(?) (in the early 1980's?).  

These programs tend to represent on the order of 1-10 man-years of
work and perhaps 20K lines of code.  Programming efficiency is often
as much of a consideration as run-time efficiency -- Go programmers
tend to play the game *much* better than their programs and have an
abundance of information about the game that they'd teach their
programs if the task could be accomplished in a reasonable amount of
time.

I'm writing my own Go-playing program (not (yet?) one of the strongest
in the world:-).  I was sufficiently impressed by some of the rapid
prototyping arguments that I'd seen (and by my own experience with
small Lisp programs) that I wrote an early implementation of my
program in Lisp (actually Scheme, since that seemed like the dialect
with the best support under Linux).  However, I ended up abandoning
that approach when I determined that -- for my programming style,
anyway -- it's painful to maintain code without static type checking
once it exceeds 1000 lines or so.  (Also (1) I couldn't find a free
Lisp implementation which both had a decent debugger and produced
efficient compiled code (or made it easy to write primitives in C),
and (2) I found that C++ constructors and destructors are a pretty
good conceptual fit to a lot of the things which go on in my program,
and I missed them in my higher-level code.)

I'm now a little skeptical about the competitive advantages that
Richard Pitre describes.  My personal experience may have been
distorted by my relative inexperience in Lisp.  (I've been programming
in in C, C++, and assembler for more than 15 years, while I've only
spent months programming in Lisp.)  For that matter, the relative
scarcity of successful Lisp game-playing programs may reflect the
relative Lisp inexperience of the programmer population at large.
However, the lack of conspicuous success for Lisp programs in this
field does seem to give a sort of upper bound for the competitive
advantage of Lisp as a language to express algorithms to solve this
kind of problem -- especially since one of the top ten programs was
originally written in Lisp.  (BTW, I have seen marketing failures and
programmer ignorance cited as explanations for Lisp's relative
obscurity.  I submit that if Lisp is just as obscure in direct
machine-to-machine contests as it is in contests mediated by
marketing, media, and purchasing droids, one must wonder about such
explanations..)

  Bill Newman

PS. I still like various things about Lisp, and I particularly miss
garbage collection for early prototypes.  Once I understand a problem
well enough to do a clean top-down design, C++ makes it it's pretty
easy to do without GC in 90+% of the cases I've run into so far.
However, in one complicated case I ended up writing a 500-line Lisp
prototype before I understood the problem well enough to start my C++
coding..
