Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!h.gp.cs.cmu.edu!Rick.Busdiecker@cs.cmu.edu From: Rick.Busdiecker@cs.cmu.edu Newsgroups: comp.lang.clos Subject: Re: CLOS' popularity Summary: Good News, Bad News and How to Win Big? Message-ID: <13168@pt.cs.cmu.edu> Date: 23 May 91 14:46:18 GMT References: <16144.9105222015@subnode.aiai.ed.ac.uk> Sender: rfb@h.gp.cs.cmu.edu Distribution: inet Lines: 107 In-reply-to: jeff@aiai.edinburgh.ac.uk's message of 22 May 91 20:15:01 GMT 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)