Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!columbia!mammoth!fox
From: fox@mammoth.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Facc mini-review
Message-ID: <4666@columbia.UUCP>
Date: Fri, 5-Jun-87 15:40:55 EDT
Article-I.D.: columbia.4666
Posted: Fri Jun  5 15:40:55 1987
Date-Received: Sat, 6-Jun-87 19:46:53 EDT
References: <8706051011.AA10783@cory.Berkeley.EDU>
Sender: nobody@columbia.UUCP
Reply-To: fox@mammoth.UUCP (David Fox)
Organization: Columbia University CS Department
Lines: 24

>
>>	I had considered the popularity based replacement algorithm but
>>rejected it due  to  the simplicity inherent in the LRU algorithm which
>>Facc *does* use...
>	One modification (which I doubt Perry is using, but *hey*, here's an 
>idea for an improvement!), is to remove data blocks from the cache in reverse 
>order on the assumption that if the file is too big for the cache, the second 
>reading of the file will still find some blocks in the cache...

Perry, have you considered using the Optimal Page Replacement algorithm?
I quote from "Operating Systems - Design and Implementation" by A. S.
Tannenbaum:

	The Algorithm goes like this.  At the moment that a page
	fault occurs, some set of pages is in memory.  ...  Each
	page [is] labeled with the number of instructions that 
	will be executed before that page is [next] referenced. ...
	The optimal page algorithm simply says that the page with
	the highest label should be removed.

Elegant, no?  There is, however, some overhead involved in computing the
labels...	:-)

David Fox