Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp - the Summary Message-ID: <4472@skye.ed.ac.uk> Date: 11 Apr 91 17:42:35 GMT References: Reply-To: jeff@aiai.UUCP (Jeff Dalton) Distribution: comp Organization: AIAI, University of Edinburgh, Scotland Lines: 144 In article weinrich@clarity.Princeton.EDU (Tim Weinrich) writes: > > About a week ago, I posted a notice to comp.lang.lisp asking people >for a comparison of Lucid (Sun) Common Lisp and Allegro (Franz) Common >Lisp. Here is a summary of the responses I have received to date. Your summary was interesting an informative, but I would like to caution people against basing any decision on it without further investigation. Indeed, a number of the comments seem to me to be false. I don't think anyone is being deliberately misleading, but everyone will, of necessity, have only a partial picture. Moreover, whenever someone says something such as "the compiler is buggy" or "compiled code is slow", they really ought to say what version of the system was used, what machine it ran on (and especially how much memory it had), and what the program was doing. A problem in one area does nto necessarily show there are similar problems elsewhere. It often makes a huge difference which release of a system one uses. Serious problems in one release are often fixed in the next, and the major releases (3 vs 2, say) of Lucid and Allegro have involved very significant changes (such as a different gc method or a new compiler). I have used a number of different Common Lisps over the years, including several versions of Lucid (starting with 1.2) and two of Allegro. (I once counted the number of CLs on nearby machines and found about 12, though there aren't so many now.) All of them have had some good features, and some bad ones. I don't think I could make a definite claim as to which one was best. However, it's worth bearing in mind that there can be good reasons for choosing one over another quite apart from which one is really best. For example, if you want to run ART or KEE on a Sun, you'll need Lucid. If you have a small machine and are not going to run huge programs (because then you'll lose anyway), you may do well to use KCL. > The two issues which spawned the most disagreement were those of >execution speed and overall compiler quality. Two unaffiliated >sources claim to have done speed comparisons: One claimed Lucid was >faster by almost a factor of two. The other (the magazine article) >claimed Franz was faster by at least a factor of two. This may be >partly explained by the fact (agreed upon by everyone who commented) >that Lucid's memory requirements are much larger than those of Franz. I have not made a direct comparison because I have never had both on the same hardware. This is about to change, so get back to me in about a month. >So the execution speed may depend upon how much memory you have. (If >this is the case, then the picture is further confused by the fact >that Lucid is now said to have a "tree-shaker" to reduce the size of >executables. I dont know how well it works or if Franz has one.) Franz is supposed to have a similar facility, but I don't see anything about it in the 4.0 User Guide. > One respondent claimed the Franz compiler was buggy and produced >buggy code on at least two different examples of correct Lisp source. >(But it is not clear to me how recently that experience occurred.) The >Franz representative, paradoxically, praised the accuracy and safety >of their compiled code as its most salient feature. No one else had >any complaints or compliments about either compiler's accuracy. People here have encountered bugs in both Lucid and Allegro. I don't have a good feel for which is more sound. We still run KEE in version 2.1 of Lucid because (I am told) of bugs in version 3. However, the bugs are not so severe that we do not also use KEE with version 3. On Sun 3/260s with 16 megabytes of memory (but different versions of SunOS), the 2.1 version is faster for smaller applications but slower for larger ones. Faster still is a 3/60 with 24 megabytes (and KEE on Lucid 3). So the amount of memory is very significant. > Two respondents thought that Franz was "buggy", but one or both of >those were running an out-dated version. A third source (myself), >thought that Lucid had more incompatibilities with Steele, volume I. >One source claimed that Lucid covers Steele, volume II, and Franz does >not. So far as I can tell, both have some things from CLtL II but not all of them. Someone claimed that Allegro did not use the new CL condition system. According to the Rel 4.0 User Guide, that is not true; but I have not yet installed the system and found out exactly how it works. It is certainly not the case that Allegro is a "letter-of-the-law-and- nothing-more" implementation. It has stack groups, processes, weak vectors, an advice facility, Flavors, Common Windows, etc. >Three out of four people who commented seemed to prefer Franz's >extensions to Steele. (The fourth was the Lucid employee). Two of >those who preferred Franz specifically mentioned Franz's run-program >function - so this observation might be biased by the emphasis my >original note placed on this one feature. Both Allegro and Lucid can run programs, and both have a foreign function interface. Their capabilities seem roughly equivalent, but I'd have to check to be sure. > Window support: Reading between the lines, I infer that Franz has a >longer history of supporting X windows than Lucid, but Lucid supports >more different windowing systems. (One respondent thought that Lucid >still does not support X windows, but I'm inclined to disbelieve this >because another person claims to have used it.) I'm told they both >support Common Windows now. One person expressed a marked dislike for >Lucid's window tool kit. I don't know how well Ludid works with X. At least thought Rel 3, it created a single window in Sunview and then did its own windows inside it. > Out of six sources who commented on the tty debugger (including the >Lucid employee, the Franz employee, myself, and the magazine article), >all but one preferred the Lucid debugger. The one exception, the >Franz employee, thought they were comparable. This does not include >the few comments I got concerning window debuggers, which seemed too >vague to summarize. I found the Allegro tty debugger (Rel 3) very uninformative. This is somewhat strange since I don't feel the same way about the debugger in Composer and they supposedly provide the same information. Lucid seems to provide better support for tracing and debugging local functions (defined by FLET or LABELS). >Ibuki CL, which is --- as far as I know --- a preprocessor to C; Ibuki is based on Kyoto Common Lisp (KCL). The KCL compiler emits C code. I think it's unfair to call it a preprocessor, because that might be taken to imply a more direct translation then is actually the case. The main problems with compiling to C are that it is harder to do some optimizations and that compilation is much slower. On the other hand, KCL is very portable and, if you use a good C compiler, the final code can be very good. -- jd