🚀 go-pugleaf

In article <494@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes:
>Barry Shein writes, discussing large-memory lisp applications:
>
>>Now, ok, you eliminated paging, garbage collection has become a field
>>service thing. But, could you do anything useful with all that memory
>>and that (relatively) itty-bitty processor? How long would it take you
>>to do a MEMQ of a list of a few HUNDRED MILLION lisp objects long?
>>etc.  Paging is only an advantage at some interim and relatively low
>>point (100-200MB perhaps, probably less.)
>
>I think I, and perhaps others, have lost the thread of the argument.  Barry's
>original attack on very large memories seemed to be that any system frequently
>needed to perform background/service tasks that were linear in the size of

	[deleted rebuttal to Mr. Shein]

>they will be in a very complex data structure, so that access to an arbitrary
>lisp object requires sublinear time (e.g. a binary tree, implying that getting
>a particular object would take only log(10^8) [maybe order 30?] accesses for
>that 100 million example.
>
>Have I missed something important here?

No, that's exactly what I have been trying to say.  Memory access in many
symbolic applications uses complex indexing and search strategies.  The access
is neither linear nor complete.  An application may build a complex data
structure and then not even use most of it!!  There are too many number
crunchers out there.  We aren't all doing matrix and array equations.

Jim Nusbaum


-- 
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%duke@csnet-relay