Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!lll-lcc!well!perry
From: perry@well.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Facc mini-review
Message-ID: <3224@well.UUCP>
Date: Thu, 4-Jun-87 03:06:16 EDT
Article-I.D.: well.3224
Posted: Thu Jun  4 03:06:16 1987
Date-Received: Sat, 6-Jun-87 06:46:58 EDT
References: <326@esunix.UUCP> <2901@cit-vax.Caltech.Edu> <344@rocky.STANFORD.EDU>
Lines: 20
Keywords: facc cache disk accelerator nice program
Summary: Yes, Facc is LRU.

In article <344@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes:
> walton@tybalt.caltech.edu (Steve Walton) writes:
> >
> > (talks about popularity based replacement algorithm)
> 
> (talks about LRU based replacement algorithm)

Tomas And Steve,

	I had considered the popularity based replacement algorithm but
rejected it due  to  the simplicity inherent in the LRU algorithm which
Facc *does* use. Actually,  there are three principal lists kept within
the Facc buffer structure coming together in a data structure which al-
lows Facc to  search  2048  buffers in the time AmigaDOS will search 16
buffers allocated with AddBuffers.

	The next version of Facc (as mentioned in a previous note, Facc
will  have ``perpetual''  support to owners) will  have a modified LRU,
something I've been cooking up. If  that does improve things even more,
I will implement the popularity code.