[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Risc vs Symbolics (was: Poor Sun timings, as competition...)
- To: IEXIST!att!ai.sri.com!slug@Warbucks.AI.SRI.COM
- Subject: Risc vs Symbolics (was: Poor Sun timings, as competition...)
- From: email@example.com
- Date: Thu, 16 Aug 1990 10:54:00 -0400
- In-reply-to: <19900815154745.9.SHEPARD@DARK.S&C.Dialnet.Symbolics.COM>
- Original-from: Larry Mayka <iexist!lgm>
- Supersedes: <19900816033238.8.LGM@iexist>, <19900816144440.6.LGM@iexist>
Date: Wed, 15 Aug 90 10:47 CDT
From: Tom Shepard <shepard@MCKENZIE.S&C.Dialnet.Symbolics.COM>
Date: Tue, 14 Aug 90 05:48 EDT
From: RWK@fuji.ila.com (Robert W. Kerns)
Date: Mon, 13 Aug 90 19:08 CDT
3) Continuous alert operation for extremely long periods of time. This
requires incremental garbage collection of all memory, including
compiled functions etc.
Why? This is only needed if you're dynamically creating
compiled function objects and then discarding them. Most
"continuous alert" applications aren't likely to do that;
it's sort of incompatible with their mission to invoke
the compiler a lot...
The Metering System can show where your application is consing; you then
do away with the need, or use something like resources to do explicit
storage management. You'll have to look at more than your own
application in order to be able to run without the GC. How big are your
"extremely long periods of time"?
Sorry, running without GC is out of the question. I'm trying to sell
Common Lisp/CLOS as much easier to program than C++, and reliable GC is
the one indisputable advantage I have!
My "long periods of time" are on the order of months or years.
Is this a demanding application? Of course! That's why the current
systems cost so much to build.
Lawrence G. Mayka
AT&T Bell Laboratories