Path: utzoo!bnr-vpa!bnr-fos!bigsur!bnr-rsc!bcarh61!schow
From: schow@bcarh61.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.sys.ibm.pc
Subject: Re: (Disk) Cache problems...
Message-ID: <1577@bnr-rsc.UUCP>
Date: 26 Nov 89 05:31:38 GMT
References: <638@ariadne.csi.forth.GR> <4383.256e9ea1@uwovax.uwo.ca>
Sender: news@bnr-rsc.UUCP
Reply-To: bcarh61!schow@bnr-rsc.UUCP (Stanley T.H. Chow)
Distribution: comp
Organization: BNR Ottawa, Canada
Lines: 55
Summary:
Followup-To:
Keywords:

In article <4383.256e9ea1@uwovax.uwo.ca> 16012_3045@uwovax.uwo.ca (Paul Gomme) writes:
>In article <638@ariadne.csi.forth.GR>, bluguras@csi.forth.gr (Blougouras Dimitris) writes:
>> Problem : CACHE programs.
>> Machine : IBM AT 6Mhz, 30 Meg. Hard disk, 1.5 Meg. extended memory.
>> Symptom : 
>>                          No Cache     |  PC-CACHE  
>>                         --------------+---------------
>>           Norton's DI      1.9        |    4.9    
>>           Coretest       202.9 Kb/sec |  985.6 Kb/sec
>>           Compiling       77 sec      |   75 sec
>>     
>>           This means that when I compile a C program I develop, I see NO
>>           difference in compile times, whether using the cache or not.
>>           I notice the same phenomenon even when I use the Compaq's or
>>           Zenith's Cache programs, but I mention PC-CACHE because its 
>>           performance is the best of all.
>>           (I use command line version of Microsoft C 5.1 and/or Quick C)
>> Question: What is going on there?

Since you are running on a relatively slow machine, most likely you are
spending your time waiting for the CPU to actually do the cmpile. In
this case, disk-caching will not help you.

I have used PC-Cache versions 4 & 5 [BTW, the whole PC-Tools set is
highly recommanded and a great bargain]. They are indeed good. Central
Point Software licenses them from Multi-soft's Super PC-Kiwk. This is a
Superb disk caching program, faster even than PC-cache.

>
>Is the above a single, one-time compile?  If so, there's nothing in the cache
>to substantially improve performance.  

This is not quite true. Many disk cache programs will do "Read-Ahead"
of full-track reads. This means your program asks for a sector, the
cacher will read the sector, hand it to your program , than go and
read the whole track. By the time your program wants the next sector,
it will already be there!

Depending on the file locations and cache size, caching can cut down
on thrashing as well. (Normally small gain, but occasionally big). In
the case of Super PC-Kiwk, it also optionally does write-buffering. This
allows the CPU to go on while the cache takes care of writing.

The true test is to run the compile from RAM disk and see what the
difference is. A good cacher will come close to the RAM disk times.

Also,  as Paul points out, cache works best when the same file is
accessed repeatedly. This means your cache must be big enough to keep
the files around. A mega-byte or two is often enough. 256K is definitly
not.

Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh61
Me? Represent other people? Don't make them laugh so hard.