shollen@wright.EDU (Sheila Hollenbaugh) (05/21/87)
We are looking for a version of Common Lisp which will run on a SUN-3.
We are aware that Franz and SUN(Lucid) have versions available. We
would be interested in knowing if there are any other options, and what
experiences any users have had with Common Lisp on the SUN-3.
Thanks for your help.
Sheila Hollenbaugh
Wright State University
<shollen@wright.EDU>rjn@duke.cs.duke.edu (R. James Nusbaum) (05/21/87)
In article <132@wright.EDU> shollen@wright.EDU (Sheila Hollenbaugh) writes: >We are looking for a version of Common Lisp which will run on a SUN-3. >We are aware that Franz and SUN(Lucid) have versions available. We >would be interested in knowing if there are any other options, and what >experiences any users have had with Common Lisp on the SUN-3. >Thanks for your help. > > Sheila Hollenbaugh > Wright State University > <shollen@wright.EDU> The following comments were received as replies to a network posting asking for comments and experiences with Common Lisp systems for Sun workstations. I especially asked about good compilers, access to functions written in another language (necessary to get access to things like SunWindows,X, etc) and performance. -"We have had good luck with the Franz Common Lisp. I think they might also be willing to make allowances for educational institutions. Franz is about as small and fast as any Common Lisp. However, it doesn't use the facilities of the Sun particularly. The debugging facilities aren't bad, but you might as well be on a timesharing system with a glass TTY."- -"We have SUN's common lisp (licensed from lucid) on our SUN3s. I haven't used it, but I manage the machines. Each client needs at least 25MB of swap space. On our 3/160C's the default swap size during setup was 23MB. lisp seems to come up ok and run with 23MB. Our 3/75's, however had a default swap size of 12MB (I think) and lisp won't start up with that little. So, I'd suggest that you check main memory, swap space and disk space needed with any lisp that you get. Lucid's common lisp has had good reviews from all I've talked too. We have it running on a VAX 8600 under Ultrix. SUN's lisp is simply lucid's with a different name on the package."- -"There are several possibilities (and i think i have used them all), but only two that i will pass on here. It is worth pointing out that i have used both of these, and played with windowing and graphics, and with Portable Common Loops (PCL) in them. My interests were primarily graphical, and i wanted an interface to SunCore on both. Never managed it in either. 1) Lucid. Good version of lisp. Graphics. Reasonable built in editor. Ok interface to foreign functions. However, lucid lisp is BIG, and keeps getting bigger. They say that in 2.0 (available now, i think) that you can configure lisp without this and that and sundry, but all the versions i have had have had everything, and the kitchen sink all inside. Garbage collection is slow too. When i run lisp here, in order to get reasonable performance, i need to keep my swap space at 50Mbytes, and lisp uses up a LARGE part of that. Of course, then garbage collection takes slightly longer than forever. They have a builtin window package that runs in sunview and can do graphics. They also supply an interface to sunview. However, the foreign function call stuff is limited and seems to me inflexible. Compiles PCL. 2) Kyoto Common Lisp. Good version (previous releases have been buggy). No graphics. No editor. Compiler produces C code which is then compiled by cc. (This makes KCL very portable - and all but one file of the source is c. On the other hand, since it needs to fork/exec cc, its somewhat slower.) Source is available. Foreign function calling is fairly straightforward. No graphics, but NeWS will be available from Sun shortly, and it is very easy to talk to NeWS. Much smaller than Lucid. Does not compile PCL with the PCL source i have, but i think that it is probably only about a days work (or so). I would choose KCL. Why? Lucid is very big, and my experience has been that they dont care about that problem, feeling that everyone should just go out and buy more hardware. They have their own way of doing things, and express little interest in what i need. They seem to want to make a system that looks like the symbolics on the sun. If that is what you want, go for it. On the other hand KCL is distributed by this crufty bunch of folks who never answer phone calls. But source is available (and inexpensive), and i have modified my source several times (among other things to build a pixrect library, took about 4 hours). KCL is smaller, more flexible - both because of its unique nature (compile lisp to c) - and because the source is available, but less well supported."- -"I wouldn't bother with the SUN, especially in a diskless configuration. I wasted (yes, wasted) nine months trying to develop an architecture simulator on Sun 2's. Little things like a server being slow can completely hang your LISP and your editor - so you sit. And sit. And forget what you were doing..."- -"You're right....don't even think about running Lisp on a Sun-2. On the other hand Sun-3's (which are three times faster in general than Sun-2's) make a fast lisp workstation. BUT, you must have enough memory on the system to make sure that you don't page when you garbage collect. I work with both Franz and Lucid Common Lisp and they both copy the workspace to garbage collect. When you have to go to the disk (or network) every time you want to garbage collect then you lose big. And then you finish GC and start doing real work again and all the pages you want have already been flushed. I suspect that the reason the limited memory isn't as much a factor with Symbolics workstations is because they do incremental garbage collection. When you are working normally everything works fast.....but go away for a while and come back and watch the swap bar turn solid black for a few seconds. Franz Common Lisp can run quite nicely in 9M of memory. Memory is real cheap these days. I have 16M on my desk and I almost never page while switching back and forth between Lisp and other windows I am using. As far as performance goes, I have seen a Sun3/160 running anywhere between .5 and 4 times a Symbolics 3600. Moving to a Sun3/260 gives you another factor of two performance improvement. Sun's can match the speed of a Symbolics workstation....now if they can just make the environment as nice."- -"I received literature yesterday which describes KYOTO COMMON LISP. It is described as a complete implementation of Common Lisp. KYOTO sells for $450(binary) and $450(sources) for the first CPU and $50 for each additional CPU in the group. A group is described as SUNs, Vax, etc."- We decided to go with Kyoto CL, but haven't got it yet. R. James Nusbaum, Duke University Computer Science Department, Durham NC 27706-2591. Phone (919)684-5110. CSNET: rjn@duke UUCP: {ihnp4!decvax}!duke!rjn ARPA: rjn@cs.duke.edu