mike@yetti.UUCP (Mike Clarkson ) (10/04/85)
[nibble, nibble.] Digital has a Common Lisp implementation on Vax/VMS. We have just received it (the first site in Canada), and have yet to receive its documentation so my exposure to it is rather cursory, but I thought I might pass on some initial impressions. It comes complete with an EMACS style editor, and appears to be a complete implementation of Common Lisp. It's *BIG*. The kernel is about 300 Vax pages (1 page = 512 bytes), and then it boots the rest of it which is in a Lisp complied format. The rest of it is > 6500 pages (>3 MEG!). It requires 8600 pages (~4.5 MEG!) of virtual memory to run. (In VMS this is the paging file quota.) It's *SLOW*. We're running a Vax 8600 with 12 Meg memory, and under normal load (50-60 users) it can take ~2 minutes just to load! Garbage collections on an 8600 at 3 a.m. with the system virtually user-free can take 2-3 minutes. (All timings very approximate.) It's not bug free. A number of simple things will make it turf its cookies and die. For example if you go into the editor and ask it to add a line to one of the buffers using the GROW-WINDOW command, all works well and the buffer is made one line larger. However a subsequent GROW-WINDOW command results in a fatal internal error in the screen editor function GROW-WINDOW-HEIGHT routine as a result of hitting a bad block address (SPR has been submitted). This is version 1.1 so given that one should never use version 1.x of anything I can't fault Dec (yet?). However there's one thing I feel is a major fault: unlike Franz Lisp which I am more familiar with, this Common Lisp does not dynamically load, or "autoload" functions that it doesn't have in it on an as-required basis. This may be common to Common Lisp, or maybe Dec didn't want source code lying around, but the result is that it boots fully loaded, all dressed, and is slow even if you don't need the whole works. This strikes me as a poor idea. In passing, I am very curious to know why Franz Lisp was not included in the set of languages that Common Lisp comprises, and what are the real philosophical differences that distinguish Common Lisp and Franz Lisp. Were there reasons why the people at Bezerkeley felt it would not be advantageous to be a part of the Common Lisp "standard", or did they feel that it would be better or simpler to add Common Lisp to Franz, rather than changing Franz to conform to Common Lisp? If anyone at Franz Inc. has could shed any light on this question I would be very interested. Either post replies, or mail to me and I'll summarise to the net. I would also be interested in hearing about other people's experiences with Vax/VMS Common Lisp. allegra \ Mike Clarkson, BITNET: decvax \ CRESS, York University, FS300013@YUSOL ihnp4 > !utzoo!yetti!mike 4700 Keele Street, linus / North York, Ontario, AT&T^G: watmath / CANADA M3J 1P3. (416) 667-3954
lamy@utai.UUCP (Francois Lamy) (10/05/85)
Concerning Vax/VMS Common Lisp: my own (very brief) experience with
Common Lisp dates from almost a year ago on a Concordia University Machine
(first in Canada, eh?). It was painfully slow, even with 1250 pages of
working set. As I recall, it was even slower than NIL when running
interpreted code, but ran faster when compiled...
Running Common Lisp on a machine with 50-60 users is perhaps asking for
trouble: it is usually suggested that each Lisp user has 2 Megs of PHYSICAL
memory available...
Jean-Francois Lamy CSNET: lamy%utai@toronto
lecturer, U. of Montreal. UUCP: {decvax,allegra,linus,utzoo}!utcsri!utai!lamy
Ph.D. student, U. Toronto.CDN: lamy@iro.udem.cdnhedrick@topaz.RUTGERS.EDU (Charles Hedrick) (10/07/85)
I don't know specifically why DEC chose not to autoload, but if their code is sharable, there are performance advantages to having the whole thing in one core image. On a VM system, the parts that you are not using should be paged out, and thus should not affect you. If more than one user is using the same thing, you would be sharing the same copy. If you autoload, unless there is a very fancy implementation, the code is loaded into memory that is dynamically allocated. This means that each user has his own copy. The exact tradeoffs depend upon details of the pager. I am assuming a pager such as TOPS-20. Your question about Franz wasn't quite clear. I hope you realize that Franz existed before the Common Lisp standard. The people at Franz, Inc. didn't have much choice about whether Common Lisp was compatible with Franz, since Franz already existed, and they didn't control the standard-making enterprise. In general I think it is fair to say that the Common Lisp definers were concerned mostly with compatibility with Lisp Machine Lisp, and that they were not concerned too much about the size of the language.
ee178acb@sdcc7.UUCP (DARIN JOHNSON) (10/10/85)
Due to the method of shareable images in VMS, I would wager that
with 30 people all doing LISP on a VAX 11/780, the VMS users would
have a smaller drop-off in system performance, than a similar Franz
environment. I admit, at the moment LISP is quite slow on VMS,
however, DEC is known to greatly improve products in later versions.
(reminds me of someone who used VAX/Ada, and examined the MACRO
listings that were produced. The Ada system was a pre-release
version. The user instantly decided his PL/1 programs were
infinately superior to Ada because "Ada doesn't do any
optimization!" {I should mention, he was comparing simple PL/1
programs with Ada programs that used generic functions, etc...})
Darin Johnson