Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!ll-xn!cit-vax!tybalt.caltech.edu!walton
From: walton@tybalt.caltech.edu.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Facc mini-review
Message-ID: <2901@cit-vax.Caltech.Edu>
Date: Tue, 2-Jun-87 09:04:33 EDT
Article-I.D.: cit-vax.2901
Posted: Tue Jun  2 09:04:33 1987
Date-Received: Thu, 4-Jun-87 02:23:48 EDT
References: <326@esunix.UUCP>
Sender: news@cit-vax.Caltech.Edu
Reply-To: walton@tybalt.caltech.edu.UUCP (Steve Walton)
Organization: Calfornia Institute of Technology
Lines: 38
Keywords: facc cache disk accelerator nice program


In the referenced article, Blaine Gardner posts a quite favorable
review of Facc.  I second that recommendation, with some measurements
attached.
     While the long time it takes to open a Workbench window is
annoying, the most time-consuming thing I do with my Amiga is "make".
So, I made some measurements to try to determine how much time Facc
saves me, and how many Facc buffers are required.  I used a floppy
with the MicroGnuEmacs Amiga and system-independent sources and did a
"make mg" with Facc installed at its default 256 buffers, and with the
number of buffers bumped to 512.  A clean copy of Facc was invoked
both times, and the objects and executables were deleted in between.
     With 512 facc buffers, "make mg" took 19 minutes.  256 facc
buffers raised that to 34 minutes.  Facc's display showed a very low
hit rate with 256 buffers (below 10% for both drives);  512 buffers
increased this to 90% for my compiler disk and almost 70% for the Mg
disk.  Similar results were obtained for "make shell."  So, it appears
that increasing the number of buffers past 512 wouldn't help this
particular application much.
     A few comments:  Facc considers a block which is written to a
disk as one which has been referenced, making the assumption that when
a file is written it will almost immediately be used as input to
another program.  I don't know to what extent this is correct, and
would have liked to try a version which ignored written blocks and
used read accesses alone as its criterion for which blocks to keep.
Also, facc treats all blocks as alike, and some kind of priority
scheme would help keep directory blocks in memory longer.  Perhaps
Facc could count the number of times one of its cached blocks is
accessed, and reuse the ones with the smallest count first;  I suspect
this might add considerably to Facc's overhead, though.
    Finally:  it is both fun and enlightening to watch Facc's display
of disk read and write accesses.  A double-click on a drawer on my
Workbench disk containing 10 tools and associated icons generated 55
(yes, 55!) read requests.

    Steve Walton, guest as walton@tybalt.caltech.edu
    AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu
"Long signatures are definitely frowned upon"--USENET posting rules