Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!odin!pcg From: pcg@odin.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: Date: 1 Mar 90 20:13:29 GMT References: <1662@aber-cs.UUCP> <43688@ames.arc.nasa.gov> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 43 In-reply-to: lamaster@ames.arc.nasa.gov's message of 26 Feb 90 03:10:43 GMT Posting-Front-End: GNU Emacs 18.47.1 of Wed Mar 15 1989 on odin (berkeley-unix) In article <43688@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: Arbitrary object lengths, on the other hand, look like an unsolved problem to me. Tell that to Burroughs... :-). There have been studies (Smalltalk: bits of history, words of advice) in object memory *with* pages; you have object memory in core (which is good), and then secondary storage transactions are done in pages, and you try to stuff a page with many small objects, hopefully related. A compacting garbage collector helps here, of course. BTW, why is "making the working set smallest" a primary goal? Working set is a performance question, and the overall best performance is the goal. For general purpose applications/architectures, minimizing the working set gives the overall best performance. >A large page size implies coarse, static grouping of objects, and >approximates the correct policy, and poorly, only in the case of sequential >access, It also approximates correct policy on array dominated simulations where you can, on some systems, require touching 24 bytes or more of data for every CPU cycle. As usual: if we are talking about special purpose architectures, then things may dramtically change. After all Cray is fond of base+limit, and for good reason, for his vector machines. We were discussing 64 bit machines; not all machines with 64 bit addressing will be used for vector processing. Somebody said that they may well be used for hypermedia, or databases, or many other things that resemble the classic timesharing computer utility concept. What I really don't like is SUN having large (8KByte) pages on machines that are rarely used for sequential access, and their only excuse being having misdesigned the MMU architecture. :-(. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk