michaelm@bcsaic.UUCP (michael b maxwell) (11/27/85)
It is now a couple months since my original posting concerning the benifits of converting Lisp programs to C (in terms of speed, etc.). Since a few people asked me to post the results, I'm doing so. The trouble is, I don't have many results to post which didn't already appear on the net, and very little even there. A few notes: 1: Jay Freeman (spar!freeman) observed that real-time systems need incremental garbage collection, something which many lisps don't provide. 2: Jim Kempf (hplabs!kempf) says: > If you want to recode in C, then profiling > tools are absolutely essential for determining what parts to recode. > One possibility for avoiding recoding is to track down what parts > of the code are heavily consing and preallocate where necessary, > if storage is being allocated and thrown away within a single routine. > We have found that removing this kind of consing from within an > interface to a Pascal database reduced by almost a factor of 2 the > amount of time for the Lisp to Pascal database calls. 3: In a posted message that I won't repeat here, John Nagle (wdl1!jbn) discussed the conversion of an "expert system" (the Ventilator Manager) which was converted from EMYCIN to (gasp!) BASIC, which conversion made it a real-time system. But it appears that it wasn't really an expert system problem in the first place, rather a process control problem, so maybe this isn't typical. 4: There was considerable discussion (mainly in net.lang.c) about garbage collection methods, which I won't attempt to summarize here. Peter Ashwood-Smith (utzoo!hcrvax!petera) suggested that "simple programs (where you know you are not going to run out of memory doing one 'evaluation') are probably more effecient when written in C." I know that several groups have created programs in Lisp, then recoded in C, but either they aren't listening, or they don't have time to post any info on speed-up they may have (or pointers to published references). My original msg asked "Have many people really done the translation? Or is it one of those things that everyone talks about, but no one does anything about? :-)" Perhaps the ":-)" wasn't appropriate; maybe no one *does* do anything about it! -- Mike Maxwell Boeing Artificial Intelligence Center ...uw-beaver!uw-june!bcsaic!michaelm
root@topaz.RUTGERS.EDU (Charles Root) (12/02/85)
I conjecture that you didn't hear much about Lisp to C conversion because it isn't often done. It is fairly common to do research using a Lisp prototype and then build a second-generation system. It would be reasonable for this second-generation system to be in C. However the gains there are not due to conversion from Lisp to some other language, but from using a more highly-tuned implementation. There is no reason to think that a simple translation from Lisp to C would gain anything, if the original Lisp program was a sensible one. Of course if the original program was ill-suited to Lisp (e.g. floating point array computations in a dialect of Lisp that doesn't do a good job with this), then a translation might make sense. The quality of existing Lisp compilers seems about as good as existing C compilers. Indeed the most widespread Lisp system that I know of (Utah's Portable Standard Lisp) does more optimization than the most widespread C system that I know of (various versions of PCC and Berkeley's compilers). The main limitation in the Lisp compilers I know about is in dealing with heavy numerical computing. This is not because the compilers are stupid, but because of Lisp's nature as a typeless language. (Of course there are implementations that allow type declarations.)
mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (12/05/85)
In case it got misssed, the last (?) SIGART Newsletter (No. 94, Oct. 85) had a paper by Bruce Wilcox "Reflections on Building Two Go Programs" wherein he describes the lessons learned from writing a medium-sized LISP program, then re-writing it in C. There's not much in it on the port problems; you can probably summarize what there is as "Not worth the effort in current environments." <mike