tgd@ORSTCS.CS.ORST.EDU (Tom Dietterich) (11/20/87)
Has anyone written any large common lisp programs in Lyric on the 1108? We have found Lyric to be essentially unusable because it is too slow and there is not enough stack space to do interpreted execution of sizable programs for debugging. We've stopped running background processes because we need the stack space. Is anyone else out there having these problems? I'm curious if a substantial portion of the developers have ever run Lyric on anything except an 8Meg 1132. --Tom Dietterich tgd@cs.orst.edu
Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) (11/22/87)
Tom -
I have encountered stack space warnings when running MM-D interpreted.
[MM-D is my hybrid Interlisp/Common Lisp client for the distributed mail
system I'm developing.] MM-D isn't very large compared to the humungous
expert systems that people around here run, but it uses TCP and the "move
to next message function" does some pretty gross kludgery that must eat up
lots of stack space. I generally have no problems when running it compiled.
I wonder if I can program around this problem. What I'm trying to do is
to re-stuff a TEDIT window from a stringstream, tossing out what was in there
before. I had mucho problems in Koto before I got it to work, but in Lyric
it didn't work. Part of the problem was that the current process is the
TEDIT process I'm stepping on. I ended up spawning a new process with a
window at the same position, moving the old window off the screen, closing
the old window, then committing hara-kiri via DEL.PROCESS! I hope there's
a better way, but I haven't been able to find it...
-- Mark --
-------SCHMIDT@SUMEX-AIM.STANFORD.EDU (Christopher Schmidt) (11/23/87)
Has anyone written any large common lisp programs in Lyric on the 1108?
We have found Lyric to be essentially unusable because it is too slow
and there is not enough stack space to do interpreted execution of
sizable programs for debugging. We've stopped running background
processes because we need the stack space.
We did find that Lyric is unusably slow on our 1108-105's, but it was our
conclusion that the problem is that the size of the working set of even
the minimal sysout is just too big for 1.5 Mb of memory to cope with.
Indeed, our 1108-110's (which differ from the 1108-105's only in that
they have 3.7 Mb of memory) do not suffer the same swapping problem and
are *much* more usable. I am surprised that if you have 3.7 Mb of memory
in your machines that you find them much slower than when using Koto.
I've not run much interpreted code on the 1108-110, though. Maybe that's
the difference between your experience and mine? Try using the compiler
more and see if that helps. I guarantee it will cut down your stack
usage by at least a factor of 4.
On our dandetigers and doves (with 3.7 or 3.8 Mb of memory in all
cases), Lyric is actually a little faster than Koto. We believe this
is because both ASSOC and GETPROP are in microcode. (In the past,
either one or the other opcode has faulted back to macrocode.) The
microcode is 20% larger, but we haven't made any fine-grained attempt
to figure out what has been speeded up.
The Common Lisp compiler hasn't yet had as many optimizers added to it
as the old Interlisp compiler did, so there is still some room for work
there. I invite readers to submit any they have written to Info-1100.
--Christopher
-------Welch%osu-20@OHIO-STATE.ARPA (Arun) (11/24/87)
> Has anyone written any large common lisp programs in Lyric on the 1108? > We have found Lyric to be essentially unusable because it is too slow > and there is not enough stack space to do interpreted execution of > sizable programs for debugging. We've stopped running background > processes because we need the stack space. (We never did get the original of this posting, so I'm copying off of Christopher's. Yes, our connection to the outside world is still off the deep end. Supposedly the PSN gets connected to the ARPANet in Jan.). We recently finished re-implementing one of our systems from Loops/Interlisp to PCL/CommonLisp, and didn't really run into any major problems with stack space, even though most of the system didn't get compiled till the end. The system and one run of the test case increased Vmem by ~15-20% on a 32Mb partition, which probably qualifies as large. In the early days of Beta-testing Lyric, however, we did try to run it on a 1.5 MB machine, and it was pretty much unusable for real work, it spent all day long swapping. It was so slow, in fact, that it couldn't deal with the network, since all the connections would time out waiting for it to process... We haven't tried it on a machine that small since then. In some cases of the IdleFns, I've noticed that my Dove is faster than some of the dandelions we've got here, but slower than the -tigers. On the other hand, my officemates Dove is slower than the dandelions for those same Idlefns. I'm running version 127 of the microcode, and she's running 130, but I haven't really had time to see if that's the problem or not. ...arun -------
kiewiet.pasa@XEROX.COM (11/25/87)
Regarding "On the other hand, my officemates Dove is slower than the dandelions for those same Idlefns. I'm running version 127 of the microcode, and she's running 130, but I haven't really had time to see if that's the problem or not." The 1108 microcode version for Lyric is 153 and the 1186 version is 87. --Lorraine
ferris.pa@XEROX.COM (12/01/87)
Tom Are you certain you've recd the official product release version of Lyric? Normally I personally installed all the first releases but Beta sites were handled differently. Let me know if you need it. don