🚀 go-pugleaf

In article <16144.9105222015@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.uk (Jeff Dalton) writes:

   > ConSolve is considering porting SitePlanner to C++ because of problems
   > with LISP.  Those problems are (in order of importance to us):
   >
   > 1. Performance.  LISP code is always significantly slower than C code,
   > even if one works hard to optimize it.

   I have encountered a number of cases where Lisp code was faster than C
   or just as fast, but perhaps they are too exceptional.

Run-time compilation, in some situations, can be used to great
advantage in demonstrating performance quickly and easily in lisp that
is very difficult to match with C -- like how many C hackers have
really written code that does run-time linking?

   There are also cases where Lisp is slower for no good reason, so
   far as I could tell.

   So I think there is room for Lisp to do better here, at least for
   some applications, and I'd be interested in knowing what cases Lisp
   handles poorly.  The various Lisp implementors may be interested too.

This is a big area of frustration for me.  On the one hand, I feel that I am
constantly encountering this perceived notion that Lisp Is Slower Than C.  On
the other hand, I feel that I have a solid technical basis for claiming that
this notion of relative speed is based on semi-bogus information.  A big
problem is that it is much easier, albeit completely unnecessary, to write
correct, but *wildly* inefficient lisp code.

As a simple case in point, I once knocked more than 50% of the time out of an
commercial application with a typical running time in the 6 to 12 hour range,
by rewriting about a quarter page of code.  The code in question was MAPCARing
over the result of a MAPCAR call where the inner call used a :TEST function
which was in turning calling MAPCAR on the tail of the original list.  None of
this consing was at all necessary!  All of the partial results were `dropped on
the floor', or left for the garbage collector.  I rewrote the code such that it
produced the same result without consing.

I would like to think that this was an extremely uncommon situation, however
after having the opportunity to get up close and personal with a handful of
other large lisp applications, I now realize that extremely careless memory
management is the rule rather than the exception.  I would bet that a company
that *needed* to get their application faster could achieve similar results at
great savings by simply tuning their original application -- even if *only* for
memory management -- rather than recoding in C or C++.  I'm somewhat skeptical,
however, as to whether the typical industrial lisp hacker really understands
the issues involved well enough to do the tuning.

   > 2. Isolation from mainstream software tools.  C programmers can use,
   > for example, the Motif and Open Look GUI toolkits directly.  LISP
   > programmers either have to build a foreign function call interface to
   > a C-based application or wait for someone else to provide one.

   The interface to such tools is simple in some implementations.
   However, you are right that the implementors have to prepare the
   ground for you and that your code will be at least somewhat
   implementation-dependent.

   An approach that works well for some applications is have the graphics
   code written in C but running in a separate process connected to Lisp
   by a pipe.  Windows, menus, etc are represented on the Lisp side by a
   "handle" such as, perhaps, a string like "window-1".  Although there
   isn't any standard way to make such a pipe connection, it's fairly
   easy to do it in most Lisps.

Actually, I think that a good argument can be made that there *is* a portable
way to do this.  Given that having pipes requires having a U*ix operating
system, you can write portable C code, using the pipe-fork-n-exec model, which
starts up a lisp process with it's standard input and output streams tied to
the C program.  At the very least, this gives you portability across:

 - lisp implementations -- the lisp program just starts up normally;
   it can be prevented from accessing /dev/tty and assumed (yes,
   *some* lisp implementation, *could* meet spec and fail to deal with
   this situation -- I don't believe that that implementation exists.)
   to communicate via its standard input and output streams.  The
   reason that this cannot, strictly speaking, be firmly based within
   the Common Lisp standard is that start up and shut down are not
   standardized.  This lack is for good reason, given that the
   concepts don't fit well in, say, a lispm environment.  In any case,
   the assumptions made here about the lisp implementation really are
   quite reasonable.
 - C compilers -- In a U*ix they've all got to be able to generate
   code to make system calls.
 - U*ix implementations -- the assumptions here are that the OS must
   provide pipe(2), fork(2) and some form of exec such as execve(2).


The other thing that I hope will help to turn this situation around is
Python (Rob MacLachlan [CMU Common Lisp group]) and its presumeably
forthcoming commercial descendents.  Lisp compilers are now truly
coming of age, finally providing functionality (like source level
debugging support) that C hackers take for granted, and in addition
taking advantage of state-of-the-art optimization techniques to crank
out some truly tight code.  They might not actually eliminate
completely bogus consing (?), but they are getting to where they can
point you right at the places that are doing it.

I really think that moving from Lisp to C is a wrong approach, but I
agree that for the most part, industry appears to be moving in that
direction.
--
Rick.Busdiecker@CS.CMU.EDU
``Now, what I contend is that my body is my own, at least I have always so
  regarded it.  If I do harm through my experimenting with it, it is I who
  suffer, not the state.    - Samuel Langhorne Clemens (a.k.a. Mark Twain)